Reported by Renee Cohen
NEW SPEAKER: Can we have a volunteer for taking of notes? Do you want to
volunteer. Terrific. Dean will volunteer. Blue sheets are going around. I guess
this is, being the first meeting, there might be people here who don't know what
the blue sheets are. If you've never been to an IETF meeting, there are two
copies of a page, which is colored blue, thus the notation, blue sheet. It will
go around. Please put your name and e-mail address on it. This is an a
attendance record. All we use this for is to determine how many people are in
each room. We do this at every meeting, every meeting.
At a group like something that holds two events, you only need to sign it once,
not for each session. When you fill it out, pass it to the person next to you.
Snake it back and forth across the room, on one row and back to the other. There
are two, you only have to go halfway. Hopefully, now you understand blue sheets.
Open your registration packet and read the note well document. Normally we put
it up. But we're not quite prepared. Basically it says no confidential
information, look at R F C 20 26, if you have any questions.
Okay. Okay. Welcome, everybody. So, the agenda today is on the supplemental web
site. That's the soft armor supplemental web site. The agenda page.
We have only one announcement that I know of at the moment. Which is that there
will be a, an ad hoc on, on 32 wireless issues, in working with SIP, and on
Wednesday, at 5:30 p.M. In the D A L U T H room.
Does anybody have any comments on the charter, rather the agenda?
Okay. Without any comments, we'll go onto an update on charter work.
So, in order to save some time from the way we've been doing this in the past,
there are a lot of drafts that we've been working on that are working group
items for a while and have fairly minor changes. And so specifically, I am happy
to say that the SIP T framework and ISUP SIP documents are basically just need
to have some changes incorporated from, from the area director. And should be
ready to re submit after something date.
Also, in terms of the overlap signaling drafts, this is using ISUP overlap
signaling. This is basically ready for last call next month. If you have any
strenuous objections, please put them on the list.
Also, there's a document that is now incorporated, the work of many different
individual submissions on the same topic, which is the deaf requirements or deaf
and hard of hearing requirements. And I would like to just get an initial, you
know, initial call from anyone, is there anyone in this room, well, first of
all, how many of you have read this document? If so, please comment. Paragraph
( Please hum. )
Is there anyone who read the document and objects to the content of the document
in any serious way, other than the list. Okay. So in that case, I would like to,
I'm going to go and post a working group last call on the list, and I urge you
all to read this and make comments.
Let's see, also, there's a document which discussing in inter working issues
between SIP and e-mail and something six 4 addresses and phone numbers and SIP.
This is going to be discussed, instead of being discussed in SIPPING, it's going
to be discussed in e-mail, because they have more time than we do. It will be
discussed on Wednesday, at 9 a.M.. In salon E and F.
Let's see, what else do we have? Cc transfer, this is, it's currently, you know,
dependent on preferred places. It hasn't been updated for this meeting. There
are a couple of security concerns. Which are going to be discussed in the SIP
working group. To discuss whether these are general problems with refer or just
an application of refer that needs to be dealt with in cc transfer.
Let's see. The real time fax flows, this needs to be updated and we got a number
of comments and I think Glenn is going to make a comment on that.
NEW SPEAKER: Thanks, I just wanted to make the group aware of the I T U comments
on this particular document. The I T you U is responsible for T 38, which is the
real time fax specification that's currently in study group 16 of the I T U. At
the last meeting about a month ago, the group reviewed the previous version of
this document and they had a bunch of comments on that document and I sent them
to the list as the unofficially a son, the official version is supposed to come
from the I T U to Scott somebody. And I just to make the group aware of the, of
the various detailed comments that I won't go into here, but the, I guess, a
couple of things I'd like to just bring to the group's attention, the I T U has
combined T 38 which used to be a bunch of different documents into one document.
It used to be one document, and eats now one document. They made a few tweaks to
some technical errors that were in there that affect some of the call flows so I
want to make the group aware of that. Also, I see that it's a B C P now as
opposed to information Al. So that's a good things from the I T U's perspective.
Because they cannot reference an informational document. And the view of the
group was that they wanted to reference this as the call flows, for T 38 and
inter dependence. Because there are call flows for H two 48 and other dependence
and this work would fit in nicely with that. And to that end, what the group
would like to request is some sort of collaboration or liaison communication to
update them, when updates happen here.
Just to sort of, to keep them in the loop as it were.
NEW SPEAKER: Okay. We can ask the authors to take care of that.
NEW SPEAKER: Okay. All right. And, one final thing is that there was an
indication on the status web page for SIPPING that there was the intent to
include modem over IP work call flows in this as well. Has that changed?
NEW SPEAKER: That was the intention of the authors.
NEW SPEAKER: So the comment was, back from the I T U, was that that wasn't
appropriate, because that's new work and the T 38 is old work and it made more
sense to have that in two separate documents. So that's just a comment on that.
NEW SPEAKER: Okay. We can talk about that off line.
NEW SPEAKER: Just wanted to bring your attention to that and all the details are
on the list.
NEW SPEAKER: Before you sit down, Glenn, I asked you if you wanted to last call
your MIME type. I don't know if you saw that mail. But, we'd like you to go
forward and it would be a good idea to ask us for last call for T 38 MIME type
now so we can get it in the pipeline.
NEW SPEAKER: Yes, I had asked Ned to do that. Should I ask you instead?
NEW SPEAKER: You need to ask me to take it forward. I sent you mail about this.
NEW SPEAKER: Right, we can talk off line. Right. Thanks.
NEW SPEAKER: The last draft I have on this list, this is not by the way all the
chartered work, just the ones we can cover in the short time frame here.
The illustrious call flows draft. This has been around for a long time. Eats a
monster document. It's been difficult to review because it is so big and so
detailed. And so, Allen Johnston has asked for some people who have been
involved in SIP S to take a close look at this, especially the torture test
section. He believes that, excuse me.
( He's trying to sneeze. )
He believes that the rest of the document is, is compatible with something 9.
And the only section which needs to be updated are the sections in the back. And
you know, maybe there are some interest in adding some new specific torture
tests there.
Then we need, we basically need a thorough review, and in order to do that, we
need volunteers. And may I remind all of you that showed up at the BIS open
issues discussions for the past several IETF's that you agreed to be a volunteer
to review the documents. We don't want you to do the whole things. We just want
each people to do one section and we want lots of you to do it. If that's
successful, then try and get our last call around may.
Okay. Next up. Is Allen Johnston to talk about something I didn't hear what he
said.
Service examples.
NEW SPEAKER: Okay. I can't seem to find the Mike. I'm Allen Johnson and I'm
going to talk about the open issues in SIP service examples draft. Just a quick
note on some of the recent changes in this document. The directed call pick up
has been redone using the places header. Basically, caller sends an invite and
then receives an invite back with the replaces header in it that is essentially
in a different user something picking up that call. We made some changes to the
call park and call pick up scenario, to show the call being parked by one user
and picked up by another, which is perhaps a more useful scenario than shown
before. We made some fixes to the SDP. There were some version errors inputting
calls on hold and things like that.
And made various other BIS updates. The document should be BIS 9 compliant. So,
many eyes on that is useful as well.
Okay. Some of the open issues. Probably the biggest open issue is that the way
the call flows happen now, you see invites getting sent and replaces headers
getting built and there's no obvious way as to how that particular user agent
got the dialogue information. How did they know that this is how you build up a
places header to pick up a call? Or to take a call off park?
And of course, the way to do that, that we've read is, with a SIP call package
and use subscribe notify to basically retrieve dialogue information, so that you
can generate the appropriate replaces header to do it. And what I would like is,
is this group to take on the sit call package, perhaps based on part of
Johnson's draft there, and that way, that will significantly improve the call
park pick up directed pick up and single line extension drafts call flows.
Right now, they work, but you have to assume an Al band scheme for how you get
that information. We like to do the events package for calls, basically, which I
guess is roughly one half of the draft that's referenced up there.
NEW SPEAKER: She's saying some about a call.
NEW SPEAKER: Another open issue is getting the one open issue in the replaces
draft sorted out, and, we did, this was discussed briefly on the list. Right
now, the way the replaces draft is, if a, you get an invite with replaces and it
doesn't match a dialogue, you're still free to accept that invite and to process
it.
The change that's been suggested is to instead, if the, if you don't match a
dialogue, to instead send a 481 and reject it basically. It actually turns out
that if you combine this with the use of the require replaces header, in for
example, a ten to transfer flow, it actually has some very nice properties in
terms of, if the transfer fails.
Because you can then essentially fall back from an attend transfer to another
tend transfer or you can perhaps try to transfer in reverse, switch the targeted
and transferee.
And it gets rid of the accept contact header which is the piece of caller
preferences that we had been using to do this, but it just wasn't all that
clean.
( Attend, unattendeattendd transfers. )
NEW SPEAKER: The main issue with the accept contact was that you needed to
know that the other U A supported caller preferences and then it turned out that
the requirement to reject it if it's not U, is just a should strength not a must
strength in the document. So in this case, if you have a require replaces, then
whether you try to tend a transfer, you either get a 4 20, indicating they Done
know replaces, a 481, indicating you somehow reached the wrong U A, or you get a
200, in which case you success. Either way you know exactly which fall back to
do.
NEW SPEAKER: It's much better.
NEW SPEAKER: Okay. Another thing that's needed is the join header.
NEW SPEAKER: Another thing that is needed is a joint something and joint header
is one way to do that, to potentially solve that problem.
NEW SPEAKER: Thank you. This one is needed in the single line extension. The
idea that they have a number of, number of phones for example, in a house, one
of them is on a call, you pick up another extension, you you want an instant
conference going. The way to do that is to send an invite and to indicate that
you'd like to join the call.
Actually, right now, the service examples doesn't even have a call flow for the
single line extension, mainly because it had all these holes in it.
As I said before, I'd still like to include more caller prefs in this flow. I
think it's a much neglected draft, but I'd be interested in input from anybody
on suggestions as to how to demonstrate some of that utility in this draft.
That's basically it, I think if we can get this open issue resolved, this draft
is actually getting fairly close. If anyone else has suggestions for additional
flows they'd like, let me know. Otherwise we could finish up this draft pretty
soon.
And as always, send comments to me.
Okay. Thank you very much.
.
NEW SPEAKER: Okay. Hi, everybody. So I'm making a presentation as an individual,
on the work that we talked about last meeting, about doing a basically a re
write of the call control framework document to incorporate work from the, from
some of the application work, some of the cc models stuff that I worked on, and
the old framework document, and sort of incorporate this into a new draft.
So, the problem was, we took, we sort of had this turning for multi party
applications so we don't have a term in SIPPING for call control per se. We have
a charter for something which is a little bit more broad. Multi party
applications.
So, this sort of incorporates elements of call control, conferenceing, and the
way that applications are named and the way that applications communicate with
each other.
So we have a number of drafts on these topics, and they have inconsistent, you
know, inconsistent status and there were different working groups, et cetera, et
cetera. I have a couple of relevant drafts here. Basically, a group of six of us
met and decided to go and write a strong motivation Al requirements section, and
sort of include framework traditional IETF framework for material from various
other drafts, like cc models, conferenceing models and put them in this draft.
So, question to you guys, is: Is this what you were looking for?
So, I want to ask, how many of you have read the draft or at least skimmed it?
Okay. All right. So, I guess unless I hear a, the goal behind doing this design
team was to sort of get some initial text out there so we can, so people could
start to Polk holes in it. So now the draft is out there, and as the, you know,
the document editor, I am, I would like, I would like you to give me all of your
criticisms and all of your errors out, so we can try and incorporate whatever we
think is, you know, whatever comments we get here. I got some sort of private,
some private mail and private criticisms last time, that this was not seen so
much as a working group effort, because we had sort of a small design team that
went off and did some stuff and I did most of the actual writing, so if you've
got comments, please come talk to me, or one of the other co-authors, and send
the comments to the list. Let's do this.
Any objections? Okay. I'd like to go ahead and give the floor to other folks who
want to talk about multi party applications.
NEW SPEAKER: Oh, yeah, one more comment, since we have a little extra time
here. I want to remind all of the precentors presenters today that you should
try and focus your presentations on requirements and open issues. And, the, per
the SIP change document in the T S V area, two tasks for whether requirements
should be forwarded onto SIP are that they are applicable to SIP and they are
sufficiently general. So in your presentations if you're trying to do
requirements, that are going to trigger a SIP extension, you need to demonstrate
that they are both applicable to SIP, that means dealing with, you know, sort of
explain it why the other solutions that would be non SIP, for example, are not
applicable or not appropriate, why the SIP choice is better. And you need to
demonstrate that these requirements are general. And finally, I'd like to ask
anybody that has a presentation that deals with issues in another working group,
that you just call this out verbally. All right. Thanks.
NEW SPEAKER: Okay. Can you hear me? And good morning. My name is something I
don't understand. And I'm from somebody I don't know. And Ronnie from somewhere
and myself, have put together a draft, which is called multi media conferenceing
requirements for SIP based system. You can see this draft, and on the slide.
Our main object is to provide a guide, most probably, a SIP guide for building
SIP based multi media conferenceing applications. As you can see here, the
emphasis here is on multi media.
As opposite or as complimentary to just conference application,
( She has a bad accent and hard to understand. )
NEW SPEAKER: We do think that the timing for this work is excellent. Because we
do have on the table today, many drafts, many drafts discussing the applications
for SIP. And what we would like to bring to the table is the perspective of
multi media conferenceing, where we are dealing not only with voice only
conference application, but also voice and video and different types of data.
And what we have today in this draft is the requirements that are necessary for
participation and optional hosting of multi media conferenceing applications. In
a standard way. That means that for those of us, who are making user SIP user
agents, and want to be sure that this user agent would be able to participate in
conferenceing applications, and it's going to do so.
And the next step, the group that we see, is the next step, is to write the
framework, that would map this requirement to document describing the solutions.
And our goals during this design, our goals are very, very clear. The first one
is that we would like to provide multi media conferenceing user experience in
the same way as voice only conference application. Also, for those of us who
develop today voice only conference applications, the migration for it to work
with multi media conferenceing applications, would be easy and straightforward.
Another goal of our design is that, in addition to voice and video, and data,
user agent, voice only user agent would be able to participate in multi media
SIP conferenceing. And moreover, we think that we would, we will be able to
provide framework where even a basic SIP user agent, when a SIP user agent,
wants a conferenceing application, it will be able to be
( I don't know what she said. )
And what happens today is that all requirements that we see as necessary for
participating in well Dee well defined and user friendly conference, are spread
among different working group in IETF. And the first one is of course the
conference framework, that, that is just, was just talking about, and which we
discuss in SIPPING. The one, the other one, is the issue of capability of
exchange or declaration, which today is addressed by end user. Now, if you all
understand that the capabilities exchange or declaration issue is important for
multi media SIP host, even from point to point host, you can just imagine how
important it is for multi media applications. Where we have many users, each one
with its own something and the conference application has to deal with this many
many different applications.
Another thing is, the {nox} thing is, the incorporation in a standard manner of
data applications or data streams that we can see using the SIP control, that
they would become a part of SIP session. The first example is T-1 20, but there
are, and also, even the flow control can be seen in some proposals as a stream,
as a part of SIP.
Okay. The next one is, and this is the most controversial or the most open issue
today on our agenda, and I indicated a separate slide for this application. And
the last one, is the conference and floor control herb use. These are more
advanced features that are in, very official for conference existence. ALT in
some cases they may be optional. And these three drafts, these are just examples
for main contributions that we have today for this meeting. Addressing this herb
issue.
Okay. The next slide, the media control. First what do we mean by media control?
And, we mean always commands and indications that we would like to apply to
media streams. And for example, when we have a video stream, a specific code
deck is involved, and the transfer of this code deck, the resolution, of frame
rate, this is a kind of thing that we would like to signal. Now we do signal
them today, using S T P in the beginning of a code. And usually, we what we do,
we signal them, the maximum capabilities. Regarding specific portal or media.
But what we don't know really how to do is to signal the changes of the changes
of each one of the algorithm during the call.
Now, this changes can be as a result of some poor conditions on the networks,
and this kind of changes can be detected by the code codecs, autonomously, and
on the other hand, the same change of operation, can be, can be driven by
application. For example, if we have a conference application, and we have
participants join to the conference, the conference application, the conference
logic itself would like to, to issue this commands.
So, this is one type of media control. The other type of media control is codec
and command to codec for specific behavior. For example, invoice application, we
have on hold features. Don't transmit me this. In video, for example, it would
be, in some sort, to video free picture, freeze picture, don't show this
picture, don't show the applet, of the picture.
And another example in video would be send me the whole picture as a contrast to
sending changes, changes of the picture. Which is usually done during the
transmission of media or video stream.
Now, the problems that we have today, that part of this commands are defined in
S T P, and another part, actually, is defined in drafts of A B T. R T P and RTC
P. And of course we know that R T P and RTC P is not reliable and it's yet
another problem.
And so, the issue here is that it, it, we can implement multi media conference
applications and multi media point applications, using this scheme or using this
draft and work. But, if we go this way, it should be a conscious decision of
SIP. Because really SIP matter, SIP based applications matter, and not
specifically A D P matter or user matter.
So, these are examples, A V T options and the two drafts on the table today for
A T P and of course, that would be at the conference, but we have to understand
the meaning of it for SIP applications. And we have been music options and SDP
and part of the commands for voice applications we have them today in SDP. And
maybe today in some other place, and this is the question, that we need to do
some kind of ad hoc meeting, I have heard about BOF, suggestions, this is the
question.
NEW SPEAKER: On the working group, I moon, the very topic you want to
resolve, was exactly your issue the N music working group. That's exactly what
this was set up to do.
NEW SPEAKER: Okay.
NEW SPEAKER: And while, basically, we are at the same position ten years later.
No, it's -- and if we have analyze that, I was looking at the draft, and the
full draft, and it's, there is one thing that is clear in your requirement, that
the simple U A can be able to participate in a conference like a SIP phone can
today. But apart from that, everything else, basically, is a route call, and in
the domain of another am cases. All the I Ds flow and all of that, are typically
another applications. So if I, if I had going for an option. I say your 4th
option is the right one.
NEW SPEAKER: I'm sorry. The last comment?
NEW SPEAKER: I think that the, there has to be, basically, the control media is
another media in a session, and it should be treated as another media in the
session, and parlayed to all your video, whatever. And multi media in which you
give hints on how to organize a session. As such, it's really a phone option,
that we have to set up, some D P work, to define this media, and guess what,
they have an example.
AUDIENCE MEMBER: May we, I sympathized with that, because when we had the same
internal discussion on this, I think we came even more pronounced after I get a
chance to stand up after she's done. And is that this falls somewhere in between
what it is and the people have base very strong opinions, that it is just like,
fortunately, it's just like not quite anything, because it is not media in a
useful sense, from a session set upper expect tiff, because it has unlike other
media streams, it has more direct relationships to them being rather independent
than another audio video stream. As I will try to point out in my little
discussion in a few minutes, it's usually used as some of the concepts which we
have used for SIPPING, for SIP event model, because much of what we have in some
of the control am cases are indeed event, but it is not completely described by
that, so it's not appropriate to just use it as that.
So it's falls un comfortably between that. The N music, I think have officially
given up on the idea to solve the much larger and much much harder problem of a
fully distributed, I think one of E Ms actually stands for multi cast, or,
NEW SPEAKER: Multi something.
NEW SPEAKER: It was at least designed, recently, the intent was for large multi
cast type of conferenceing and I think most people have given up on the idea of
practicality and interest issues. So pitching it back to N music may or may not
be appropriate. Depending on what the solution looks like, we'll actually use
things which are outside of the N music context. So I don't think re in vents
another event is necessarily a fast path forward.
NEW SPEAKER: Okay.
NEW SPEAKER: As was pointed out. It was working on for ten years, without
significant progress so I like to not add another ten years.
NEW SPEAKER: It looks like we do need a something for this. So, going forward,
from our perfect per perspective, is that we would like to write a framework
that writes all the requirements for the solutions and basically, this framework
is going to be in our opinion, in our view, is a set of pointers to existing
drafts and approaching, of SIP working group, N music working group and N
working group, whenever possible, that would construct a clear picture, which is
really required for user agent to be able to participate in multi media
conferenceing of am cases. And in those cases where the user agent is not going
to implement specific issues, it would be, we would like to make clear what
applications would be for user agent.
As a part of this work, of course, we are going to provide in roads to multi
party application framework that was discussed here. And that is all. Thank you.
NEW SPEAKER: One of the things that I was struggling with in reading this
draft is, it presumes a certain boundary around what a conferenceing application
is. And the idea that people have an intuitive understanding of exactly what a
conferenceing application is. And that understanding seems to be based on sort
of like the classic notion of conferenceing applications that people have been
doing say, for the last ten or fifteen years. What about other models? That
aren't classic conferenceing models? Collaborative computing models?
For example, in which media just exists in a collaborative computing context as
opposed to a classic conference application? Are you going to dry to encompass
that? Or is that out of scope and you want to rep indicate the existing
application model of what a multi media conference is, using a new set of
mechanisms?
NEW SPEAKER: I would offer this way. I don't think we,
( Would answer this way. )
It's definitely not our goal, or not our intention, to replicate, the user, the
user experience that users have today in conferenceing applications. Meaning
that, it is, we do see kind of application, collaborative and includes voice
media and all other types of data. It's not restricted by the user experience
that we have today.
On the other hand, what we did mean by our conferenceing multi something
application, is, is the case where the media, at least part of the media is
processed by central entity, the media itself. And by the way, it's interesting
to note that the rest of the draft, the rest of the drafts that we have today,
on our table, I would say, all of them, all the practical drafts, except for the
framework, they address this model and only this model asses well. Because this
is the most practical way, and I wouldn't say architecture, but, but mostly from
a user experience viewpoint.
NEW SPEAKER: More questions?
NEW SPEAKER: I think we should just go ahead and go to e-mail.
NEW SPEAKER: Thank you. I'm trying to focus on a somewhat subset of what some of
the issues that were talked about in the previous slide set, in the sense of a
problem, which I think is, as I mentioned in my previous talks, is somewhat
uncomfortable in the middle between probably N music and SIPPING. In the case
that it's closer related to entities that are managed and created and modified
by SIP, but in terms of the application area, it falls much closer to multi
party type of thing. So I'm not sure what to do about it. But I believe the time
has come to actually instead of just let it fall through the cracks, see what we
can actually do about this.
So, the focus here is, specifically only on one sub aspect of this, amorphous
area, which one could call conference control. So I don't even want to say what
conference control is, and what's it's related to, but it's one sub aspect,
which some subset of conferences may need. I'm not arguing here at all that
anything we can consider conferences would find these type of abstractions
useful or that there aren't other things such as collaborative computing or
whatever, that couldn't also use it. But I think we do better if we take one
particular, since this is requirements, there is a set of beta common
applications, mainly a multi party type of, multi media collaboration which may
require this.
So the conference model that I want to focus on requirement perspective, is
namely, the centralized model. That seems to have been the emerging consensus at
least. While others are interesting, they're probably sufficiently different in
terms of the mechanisms required in terms of the trust models that it may not be
particularly productive. The history may just be another lap whole, if we try to
solve everything at once.
Also, we probably can the deal with sufficiently similar, the notion of
centralized conference with application. What I mean by that, instead of having
a single logic or grade type situation, that you have assortment of leaders
which correspondence with each other and are logically correlated.
NEW SPEAKER: You mean tree.
NEW SPEAKER: A tree or a core mesh, which is like a, you have the participants
hanging off each one of those. So in those type of situations for scaling, you
could do that.
And the other conference models fully meshed model, we can probably use the same
mechanisms but it's much harder to coordinate that, so I'm not, I don't think,
I'm, given there isn't much interest in that model anyway, I think it's probably
a waste of time at this point to go to therefrom a requirements perspective.
Multi cast, probably not appropriate, in the sense of the environment
sufficiently different for fully distributed classical IP multi cast, but it may
actually turn out for S S M, for single source multi cast, for a conference
application where you have everybody sending media to a single multi cast for
scale ability reason, this may also apply. So similar, sort of a basic common
requirement or the common core about this makes conference control resource
control, makes sense, in an environment where you have a single media choke
point in the sense there is a single controlling entity, logically speaking.
So, what are some of the functions that we might need to address in these type
of environments? We want to support this throughout the conference life cycle.
We need to support functionality throughout the conference life cycle, through
the type of conferences I just mentioned. So we need to create new conferences
that are available for example, we need to define the properties. Since they
have properties which are different from typical point to point calls in the
sense that we may need to do some sort of resource control on it, in the sense
of giving the duration, because media mixing resources might be involved.
The media, number of users is set because it's needed to do corporate resource
planning. We may want to do mass invitation, that's another thing which has been
mentioned. Again, I'm just listing requirements here.
And the question that, the open issue is this something which is really beyond,
is this high priority, through the current ad hoc mechanisms to be sufficiently
covering our needs that we need? The second area which one needs to conference,
is possibly user management, namely the admission and possibly ejection of
members again, from a central, only makes sense in a centralized conference.
Does not make sense in a fully distributed conference, where other needs are
probably more appropriate.
The admission of users, the question there is, again, this is where this
uncomfortably sits between a mechanism, versus a requirement application
perspective, is this actually somewhat similar to the notion that we have in the
simple context, namely where just like in a subscribe type of presence
environment, where we need to authorize users to subscribe to my presence, is
this a similar model that we need to have for admission and conferences? Is that
logical?
It seems in initial thought, it might be a strong correlation between the two.
In terms of a synchronous tea, and hiding et cetera. There's some others with
less of importance. And the second but final one is the SIP resource action,
also known as flow control. But I would like to avoid the use of floor control
because it has a notion of only being media and as was pointed out, I think this
is slightly more generic that may turn out to be useful beyond that.
Clearly not all conferences need all functions.
NEW SPEAKER: I wanted to agree strongly, that I think you've hit the nail on the
head with the simple model authorization. Even this thing about kicking people
out of the conference, we have the same problem for presence. So if I subscribe
and you decide you don't want me to know anymore. The way we model that you
simply change the overarching loosely correlated authorization policy and that
trickles down to subscription.
NEW SPEAKER: Yes, there's a slight difference in the sense that, if you, if I
move your subscription, you just won't get future notifies. If I remove you from
a conference, --
NEW SPEAKER: There's a explicit notify, in the case of simple. There's an
explicit, you know, good-bye, you've been rejected. We had that, so it's exactly
the same.
NEW SPEAKER: Again, that's why, I mean, in the sense that some of the
techniques, are somewhat evolved. The notion of what you're managing is very
different.
NEW SPEAKER: Right. And the key criteria, is does sort of this magic make sense
both inside and outside the conference itself. And that's the key criteria to
determine how tightly or loosely it needs to be coupled.
NEW SPEAKER: Okay. So, in terms of applicability to SIP and generality, you
haven't explicitly called that out. Do you want to do that now or later?
NEW SPEAKER: If you just give me -- I'll make sure -- okay. So, the idea is from
we've copied this mostly from a SIP creator conference, is mostly for web
interface, but that's clearly not ideal scripting and other methods. We
certainly don't want a single person doing everything. So we need multiple
support and multiple roles. The hard part, which has made the multi party, multi
task fully distributed model difficult is the issue of dealing with failures of
various parties and having the conference end in, and the other requirement is
just the usual one, I would like to provide mechanisms that we deal here with
mechanisms, but the other large whole that I think previous something that we
we're trying to do policy.
Again, floor control, hope this addresses some of what somebody said here. And
we have the notion of, we have resources which are created and actually modified
by SIP, and so, the question is, should we also, as a session management, as a
purview to SIP, conduct part of it as well. Because part of the actions which
are actually incurred to make this resource management stick are going to be SIP
advise for example. If terms of telling somebody that they can send audio and
video and not do that.
So, generally, the problem is really more of a triggering event. I think the
management issue and resources that we might have because of audio video
limitations or shared applications, so it's not just audio video. And you want
to have mechanisms which allow both ought automated queueing type of management
as well as a moderator.
And these are, I'm not going to read through those. Treat that as an object some
of the things you might want to do. And in the interest of time, I don't think I
need to go through those. The more basic question is does it make sense at all.
So, both, all of these functions, in terms of invitations, in terms of
authorizations, are largely in the sense of you can't do one without the other.
However, a number of them actually share a common communication needs, and
that's again where the connection to SIP comes in in the sense that they can all
be roughly described as having two modes, namely, or two components, namely a
synchronous event component and a control component. So a synchronous event
component is one we already have, namely Bob joins the conference, which is call
control or SIP content. The other one, which is a related event, Cal has
released the floor, a resource, or David has requested this. So these are all
based on the sense that they're directly related, and in parts paints that the
same type of people who want the call package probably want to be notified of
those events as well or a subset.
And then we have something which very much does not fit as well into a SIP
environment, but is needed as a second half to make the events happen, is namely
the commands to the conferenceing, if you want to call them that. Namely, where
you want to have the conference resources be instructed to do something. And
some of those are SIP requests and some are probably not.
So, some of them may for example, be a refer type of thing. Or some of them may
not be be appropriately modeled as a SIP request but may be much better modeled
as a procedure call. So again, that means, is this somewhat of a dichotomy in a
sense that clearly, some of these things are very closely related to SIP call
package model and some are very closely related to SIP call conference model and
some of them are really control in the environment of a conference which is
simply sending a request to a known entity saying, do something, and then, that
may trigger event notification but the actual doing is not initiated by SIP,
because we don't necessarily want to turn that into a generic procedure for
control protocol.
NEW SPEAKER: Okay. So, so what do we want to do with this?
NEW SPEAKER: So, the question is, where would you want to go with that? Namely,
do we want to take aspects of that here, in one model would be that we would
take only the event based models, because that is likely going to be SIP events
as part of this effort here, and basically try to find homes without willing who
is pit able working groups elsewhere for the other aspects. I think that is do
able for some aspects but it needs at least based on coordination, because as I
said control and event aspect are tritely coupled in reality, in the sense that
one triggers the other, almost immediately. So I don't know exactly and it
depends really, but I've heard three suggestions so far. Namely, one is as I
said before, I just may be splitting it up, only doing event packages here, and,
or, the second one, doing ditching N music thing and hoping they finally have an
interest in this topic, and the next one is just the separate effort following
the simple model.
NEW SPEAKER: I was going to say, it seems this has as much to do with simple as
everything. All the requirements that you discussed right now, and I think
they're all good things we should have more discussion on. The traffic that's
out there right now has almost none of us and it's only in the first page so I'd
like to see more on that.
NEW SPEAKER: Yes.
NEW SPEAKER: So I think that we don't want to split the events for the things
controlled by the commands and the commands themselves in the SIP --
NEW SPEAKER: I think --
NEW SPEAKER: One of the very wise things I think in the process is that since
it's clearly an event package it's something that's allowed to be done outside
of the SIP group. So presumably whoever does the command and control thing would
then do the events package.
NEW SPEAKER: Chris somebody from breathing down my neck next, but this is work
that touches a whole bunch of different areas. And it's like out of scope for
everybody, but yet there's a lot of interest in getting it done. That's what I'd
like to see, whether it's a task group, or something else, or just an informal
gathering of getting the people who know about these different areas. Because I
think what would be bad isseis if SIPPING went off that N N music said, yeah, we
look at that 7 years ago and it's bad. But likewise, if we just say N N music
will deal with the media part, we'll deal with the high level control part, it's
just not going to mesh together.
I think
NEW SPEAKER: I think that's my main concern. Whatever we do here, I think this
is a really good approach to the issues and the question is, how can we divide
up the work such that we don't end up with situations where assumptions are
being made in one working group that don't prove true in another. The success of
many SIP applications is going to depend on a framework like this being
meaningful to the people developing the am cases. And if we don't have a
meaningful way of getting input from that community in one place, then we're not
likely going to end up with something that meshes well.
NEW SPEAKER: I think that we, when I see your proposal of components, we are
missing something.
There are three parts in this conferenceing problem. The one part which is
building a conference, which is at some level a graph of users, a graph of N T
Ps linked together. So there is graph building. And part of the problem is that
we don't have a specific graph meeting in SIP. We can build the legs of the
graph but not the graph. There is one piece of work which is building the graph.
And so far, we have only seen, because we have not addressed the issue of graph
building, we are only seeing two very naive proposals. These are not completely
connected model. And we know neither of which can scale. So we have to handle
the graph building, that's where we use the invite, the refer and the conference
and this kind of thing. That's one thing.
Then, once you have a graph, we have to handle the media transition along the
graph. And R T P-n theory was designed to do that. T-1 20 was also designed to
do that. But, we don't have any explicit control there. So the media
transmission along the graph is something we are not treating well. And that
should be another type of work.
And then, once we have a graph and we can send media on graph, we have a number
of, I would say, control applications on the graph. Like, getting the words
there, getting things about who is coming and who is leaving, getting
information about who gets the floor and who does not. Which are basically
everting. but event I N G. It's not like sending a message on a call leg. So I
would think that we should split the effort into the three components and
address them one by one.
NEW SPEAKER: I sympathized with what you're saying. My problem is what I just
heard was, once we started doing inlay, even in the simple case of the for mesh,
this was turning into a research problem which was not a clear clientele. And
so, what we know is we currently have a subset of a problem that is very old in
the sense that we have applications for it which need to do this. And what I'm
hearing from you is that a 5 year effort.
NEW SPEAKER: It's not a 5 year effort. I could have it filled is it in six
months.
NEW SPEAKER: No, I have --
NEW SPEAKER: In effect, inside this one graph, I think it's at least two or
maybe three that we're talking about. There's a media graph, because we have
mixing involved. You've got the graph of all the different call legs for the
actual control of the SIP sessions and then, essentially, you may have some
multiple people or multiple things coming out of a single end point. If you want
to be able to treat those individually, that may be a stretch. But we're talking
about at least three different topology there and each need to be handled
independently.
Basically, as I said, we tried to solve, because managing now, we have not made
progress, as I said, in roughly ten years. I don't see the users out there who
are eagerly beating our door for a general graph model. I wouldn't want to
discourage anybody from doing that, but the danger that I see, we then go down
the same discussions of architecture, so what I would like to do is, independent
of whether we want a fully graphed model, when a general graph building model,
solve the simple problem first, if it turns out later that this can be subsumed
into that, so much the better. At least we have something which is suitable as
an interim solution if you want to call it that. But at least we get some work
done. We have said, we have on the order of at least 5 years tried without
success of getting anyone sufficiently interested in this general problem. And
all the while, we have --
NEW SPEAKER: We have a lot of time. We used up plenty of time. And it's going to
be hard to get, if you want to say something very quick, go ahead and do it.
NEW SPEAKER: Yes.
NEW SPEAKER: About the organizational work. Something about the end of this
week, we're going to get this done. And there are things proposed from, and
there are things that are going to be done, are done in C, but may not get done
in C.
NEW SPEAKER: Jonathan, do you have anything quick?
NEW SPEAKER: I agree with him.
NEW SPEAKER: We're going to get started on the next thing, but clearly, there's
interest. We're going to have to work out issues associated with scope, and
jurisdiction, and the chairs will take this up with the authors, and the A Ds
and we'll figure out something to do. It's clear we've got an interest. It's in
the charter already. It's really how we're going to organize this work. We're
going to organize this work and we'll figure it out. We'll probably have more to
say at the session.
NEW SPEAKER: I'm Mary somebody. And I'm going to talk about the generic request
history capability and requirements. I'm going to stand over here so I can see.
Okay. So what we've done, basically, we're trying to layout the general problem
here. And what we've done is just taken an abstract example to try and highlight
the problem. So the fundamental problem, we believe is that information is lost
as the something is calling from the network. And also it gives you this
flexibility to do that but as you can see in the red, the C N D information is
lost. I need to step through this.
Basically, the caller is unaware of word call is going to make it's way through
the network and gets re targeted and the callee is unaware of where a call has
been, by the time it gets received. So in this example here, which as I said, is
very abstract, proxy two does not know that the C was even trying. Whether C re
directs server or whatever. And E doesn't know who the end callly, doesn't know
that C or D, the and A doesn't know that B is unavailable until he reaches
alert. So very abstract scenario here.
Then we get into a couple of little, a couple other examples, a little bit more
explicit. So basically U A sends a call to proxy one, which tries several places
before re targeting calls to the second proxy. Okay. Which tries the same
places. Beginning with the red arrow, showing that U A three and four would get
re tried. There's nothing fundamentally wrong with this. The idea here is that
you might have some, an application or you might want information as far as the
history of this call, if you will. So he can provide some sort of enhanced
services, to his client or whatever.
And the next example is a voice mail example. So U A-1 has called U AA, which
has been forwarded to U A B which ends up forwarding to a voice mail server.
Which needs information ocertain information to provide the service that it
wants to provide, as far as saving the information on who called and the reason
why it was sent to the voice mail server.
And you can look at the part of the problem that I think we found in looking at
this, trying to figure out what the general problem was here, is that each of
the specific examples you might say, you can use solution X Y Z and solve it.
For example, you can use, you know, the service context request U R Is for the
voice mail. The problem with that comes when you try to do some inter working
with the legacy systems and that sort of thing.
Okay. So this slide is just trying to summarize the proposed requirements that
we've come up with. And, the No. 1 was being able to record the old U R I and
the request with re target. We have informed the U A C when the re targeting
occurs. Provide a reason for the re targeting, and then have it possible to
check completeness of the information, the rif there's a best effort mode or a
complete mode. And we do believe that the term re targeting was used and we
followed the rules, in the re targeting or determining the request U R I target.
Okay. So, I just wanted to go ahead and highlight, there was not a lot of
discussion on the mailing list, but some of the issues that are brought up with
this draft was that it was predicated on a specific solution and it presupposes
no specific solution and the suggestions ongoing forward is to go and analyze
possible solutions.
Another issue was raced was trying to solve the problem domain. And really, what
we're trying to do is get recognition that there is a need for this generic
capability. But we find a variety of am cases, without embedding service
something to the network. And certainly, their overriding solutions could be
applied to each of the specific examples. But we believe the lost information
concept is something that's in the generic parts of it.
There was another issue raced that we were attempting to replicate legacy
services. Certainly, legacy services provide us with concrete examples if you
will. And we tried to go away from that and figure out the fundamental
technology that needs to be provided.
So basically, the questions we want to post as far as going forward, is the
general problem, is information lost worth solving? Okay. The second one was,
are the requirements in the draft sufficient to solve this problem? And one
thing that we did with the requirement, we looked at the requirements from a
code phone perspective and not necessarily a higher level. Another one would be
would example scenarios be a useful a appendix to the draft? And then the 4th
one was, should we begin evaluation of solutions.
NEW SPEAKER: So before everybody gets started at the Mike, I'd like to make sure
that we think about the discussion, and that you, if you have a specific problem
with some of the requirements but not others, that there may still be use in at
least doing certain investigation work. But you don't want to say, you know, oh,
I don't like requirement No. 6. Therefore, I think that the whole thing is
stupid.
So,
NEW SPEAKER: So, one thing that I think needs to get teased apart better than is
currently teased apart there the draft, is I think the general problem isn't
just information loss. All right. There is a problem with information loss, in
the sense that something upstream of the forked invite tree doesn't know what
happened downstream in a detailed way. And that includes the route of the tree
and the user agent.
In other words, I don't find out what happened when I request upon the user
agent. All I find is the aggregated result of that request. Client. Right. So
the information loss happens at various stages. Any proxy that forks, may not
find out about things that happened downstream, because other things fork
downstream.
So propagating information upstream I think is beyond, you know, the current
rules for re aggregate
The second piece is, actually something of a different problem. And I think
getting the scope on is it is going to be difficult. Which is telling somebody
when you issue a request, why they are getting this request. And one of the
reasons why they are getting the request may be based on information that you
got back from a prior request. And that sounds to me much more like caller
preferences.
NEW SPEAKER: And Jonathan will point out that tied up in all this is what are
the identities that get reported backwards and what are the identities that get
asserted forward when you say, oh, I tried foo, what does foo mean, and that's
an interesting problem which is tied up in all this. So I encourage us to keep,
I'd keep the upstream information propagation problem somewhat separate from the
problem of how do I tell somebody why they're receiving a request.
NEW SPEAKER: So I think that the useful thing here is not for us to think about
specific mechanism yet, but to say, you know, the problem is, a requirement is
why are you getting the request
NEW SPEAKER: I just want to structure the requirement so we don't get the full,
telling somebody why we're getting the request tied up necessarily with the same
mechanism of how information is propagated back.
NEW SPEAKER: There's a clear example of that in the scenarios given here. So we
can go back to that if you like.
NEW SPEAKER: Just want to say, I think the concentration or information loss of
the solution seems
to be everything you now need to decide when to throw information away. And we
might see some of that. You don't decide why I've got a call and then sit down
and have everything and try and work it out. That does and mean providing me
with everything about information --
NEW SPEAKER: I would agree with that in the end. We've got to work through the
details for that. Yes.
NEW SPEAKER: Yes, so, I think that there's sort of some important problems here,
but I certainly can't put my finger on this. The reason this thing suffered so
much fury and horror over the time, is that people were trying to solve specific
problems. And some of the things that, that sort of concern me about this one is
that, we're getting sort of rolled into the issue of what is identity again. And
it's a big horrible problem that we've been tackling in other places, but it
really is coupled with this. I mean, you talk about insertion of information
into a request to sort of assert something about a user identity that has seen
or whose policy has been applied to the processing of this request. So as soon
as you get that, you have questions of what types of identities you're putting
in. For example, the issue that Dave pointed out, do you really want to put
every request just when there's a change of real users. Or for, how do I know
what that is a hard question. Then you get coupled in with the questions of
privacy.
NEW SPEAKER: The question is very well. But we also need to talk in terms of re
targeting.
NEW SPEAKER: So,
NEW SPEAKER: Great
NEW SPEAKER: So the question is, how do you know that? I have no idea how to
solve that particular problem. In many cases you just don't know. So, I guess
what I'm saying is, I think we should work on this, and I think we, the group as
a whole needs to have a much more open mind about thinking about the scope of
this problem, and, I mean, it's been primarily motivated in the past by people
have gone pet problems they want to solve.
NEW SPEAKER: And my last comment is to agree with Dave of the profound slippery
slope in stating why a request was redirected. This is one of the pointing I
raced on the mailing list a long time ago. And I still think it's going to be
problematic. It doesn't mean we shouldn't explore it. But keep an open mind.
Whenever you think more broadly, there's a lot more stuff. We need to work
requirements and just requirements mostly.
NEW SPEAKER: Yes. And we're trying to focus on those.
NEW SPEAKER: Okay. If the backup to the first example, please,
NEW SPEAKER: Okay.
NEW SPEAKER: There's a clear difference in something that's happening in example
one and two. So example one, U A three is previously looked at the invite by the
time it gets to proxy two. And proxy two doesn't have any knowledge of this and
can't make a rationale decision about what to do next. So, there clearly is a
piece of information that might be be of interest to proxy two that's not here.
Now let's go over to example two.
Okay. Here, the proxy in the middle knows everything about why it's forwarding
stuff to U A B or the others. And it has every bit of information necessary to
tell U A B M, is I'm forwarding this to you from voice mail, and so, there's
every bit of information that it could possibly need is available. It could even
code that very specifically into the request U R I. What you're trying to solve
here, is an entirely different problem.
One entity or one identity at U A V M, singularly declared, behaving
differently, depending on how things got to it, and since that information is
available upstream, we just route to it a different way and it can behave
differently.
NEW SPEAKER: I agree, that would solve that one specific problem. But you also
still get into inter working herb use, when you try to inter work with legacy
servers and legacy Gateways and stuff.
NEW SPEAKER: Let's --
NEW SPEAKER: We tried to abstract that and say --
NEW SPEAKER: No solutions right now.
NEW SPEAKER: I'm sure we'll deal with the inter working otherwise. If you go to
example two, I think the primary thing to consider here is that, if you got a a,
well, let's call it a presence server for lack of a better word for it, for a
particular identity, then either it knows that information, and should be able
to make those decisions, or if you're dealing with two divide tease, the fact
that there isn't a subscription between those present servers, should, in other
words --
NEW SPEAKER: Well, provided you have --
NEW SPEAKER: Having all the pierce get information, the individual devices and
try to make a decision on that, shouldn't this be subscriptions of certain
information between presence systems and --
NEW SPEAKER: You're getting into solutions. Let's got to
(Several people talking.)
NEW SPEAKER: If we're looking at the requirements
NEW SPEAKER: I think that's going to get us in trouble. And if we push this
further back into the question of the systems that manage the identity, they
need the information, the end points don't necessarily need that information,
especially if they're making requests to --
NEW SPEAKER: You don't know. We don't want to restrict what end points do with
this information. We want to enable information, same thing with the voice mail.
We don't want to restrict how voice mail server has to work. We want --
NEW SPEAKER: So the big question.
NEW SPEAKER: All right. Time time time.
NEW SPEAKER: Take the last two.
NEW SPEAKER: Go ahead.
NEW SPEAKER: I'm going to reiterate a little bit on what Dave said, and the
requirements on pursuing this work, focusing on clearly delineating capturing
what happened to the request, and what you want the next thing in this request
path to do.
It is may be that we want to solve both of those problems in certain situations.
But in the case that you're using to drive this, and I think the primary case
that's driving behind it, you have a particular end point that is application
rich. And is application fixed. You've got an application in that end point and
you can't move it, even though the knowledge for that application may exist
somewhere else. In general, if you have a V M out there that is not a legacy
system, that was just a single identity thing that you responded to, you would
want the decisions about what to do done in this court.
NEW SPEAKER: That's right.
NEW SPEAKER: The general problem should leave that information in the core. And
you should detect when you have an application downstream and tell that
application what you are wants to do, what you want it to do, not what happened.
Maybe what you wanted it to do carries information about what happened in it.
NEW SPEAKER: But that, to me, that's very restrictive.
NEW SPEAKER: Time.
NEW SPEAKER: Okay.
NEW SPEAKER: I mean, I can --
NEW SPEAKER: All right. Yes want to leave this too far hanging, but I want to
get a sense of the, it seems to me, give me a hum if you think we ought to
continue working on this item, as opposed to dropping it. Hum if you want to
continue working on it.
NEW SPEAKER: All right. Now, there's an issue associated with splitting it into
two pieces, organizing it, et cetera. I think we, this is something I think we
have to spend more time on, whether it's on the list or find some more time in
the meeting, I don't know. I personally like the idea of splitting it. But I
think we need more views on that before we make a decision.
Again, requirements, we're only going to do the requirements. Not the mechanism.
All right. Take it away Dan.
NEW SPEAKER: All right. I'm going to talk about three drafts here that, I'm
trying to coordinate here.
NEW SPEAKER: Issues or drafts?
NEW SPEAKER: Yes. Hopefully, that we, that we did a fairly reason able attempt
to coordinate the content of these. The first draft here is the device
requirements draft, and it's sort of an overall umbrella requirements for end
points.
And within this, you know, one of the sort of areas which it covers is
configuration process itself. And there are some sister drafts, if you will.
Covering a configuration framework, and another draft covering the data
configuration data requirements for, all focused on end points that are acting
as sort of telephone like devices.
In terms of the issues that we saw on the list, in terms of the overall, or the
device requirements, there were general issues about echo cancellation. I guess
my feeling, if I can sort of test that here, why not go, that's not an end point
problem that doesn't conform to the draft. The acoustic echo cancellation, I
find two parts of that. Hands free speaker phone, which is probably not, and I
would request, is that part of the scope? And it seems to me, it's more of a
price point, vendor decision, as opposed to something that we want to dictate,
that speaker phone has a specific capability.
The hand set, you know, echo cancellation, does seem like that's something that
it's appropriate for a first draft event.
( when the one guy is talking I can't hear. )
NEW SPEAKER: Okay. Sorry. I sort of --
The framework draft is, what is a, a document that, I have to define the
abstract mechanism for providing end points. And the issues that came up on the
list is this part of SIP in general, and just kind of an overview of the draft,
really, the draft covers discovery of a configuration server, which is really
not a SIP issue. And the framework, I'm going to propose it is any more than
forming an address record or an address for the other cards on the draft.
U A enrollment is, sort of plays, the end point discover, or telling the
configuration server that it wants configuration. I don't think that's a SIP
issue and I'll explain in a men why I think it is.
Configuration retrieval is not really a SIP issue, there are protocols to solve
those problems if it should is not something that needs to be SIP.
Configuration change notification is though. And think, you know, I'll come back
to that why I think it is. And of course, the last phase is change up load. So
that user agent can't actually tell the configuration server about the
integration changes, by the end user.
So, you know, the big issue is, you know, why use SIP for configuration,
discovery and change notification? Well, I think there are a couple of aspects
of this. User roaming is I think, you know, a, an important requirement in, when
I say roaming, I mean, not in the device roaming in a mobile sense, but in terms
of these are coming up, walking up to a device and making it, you know, behave
like their own device or whatever.
But, the ability to be able to go up and move around means that you're, you
know, the end points that you need to address, is changing, and it's really
awkward if you start having to use different addressing mechanisms for your end
points than you do for the users. So the ability of, you know, if we don't use
SIP for basically for the discovery, and changing of configuration, then we have
to in vent a new sort of registry like mechanism so we have, basically, we can
say this, this user agent needs this user's configuration.
And it just seems like, it's a lot of work that probably doesn't exist yenly
elsewhere to be able to keep, you know, user profile in sink with the user.
NEW SPEAKER: So, I don't know. This issue comes up from time to time and there's
so many protocols out there for doing this sort of thing and I find it a little
hard to understand why people want to use something different. I mean, it seems
like, there seems to be a lack of understanding of protocols, for example, for
examination of how they can be used for this. I mean, it's --
NEW SPEAKER: I'm not saying there aren't notification, are you referring to dash
NEW SPEAKER: Configuration.
AUDIENCE MEMBER: Particularly configuration, that's what I mean.
NEW SPEAKER: Could you be more specific?
AUDIENCE MEMBER: Well, what about Al back for example, or D A C P?
NEW SPEAKER: Well, how, you mean, part of the problem here is discovery.
(Several people talking.)
NEW SPEAKER: It's a source of your data but how do you find out what it is, or
what you are. The whole identity problem is part of the biggest problem here.
And that's where SIP is very useful.
AUDIENCE MEMBER: So how about SLP for discovery on the L F server or D H C P for
example? That's another example.
NEW SPEAKER: I mean, there are problems there. There are problems
AUDIENCE MEMBER: Right, so look at the protocols and figure out what the problem
is, and try to enhance --
NEW SPEAKER: That's essentially done. And there are drafts that are expired
partially.
(Several people talking.)
AUDIENCE MEMBER: The problem is that, if I am sys admin and I have to deal with
20 different ways of doing discovery and 20 different ways of doing
configuration. As a sys admin I want one or if not one, then maybe two or three,
but I don't want like, for SIP to have to do one thing and for my e-mail, to
have to do something else. I want one way to configure things. Right? Or
something like that. Right? This is, this is the problem. It's not just the
actual end device. It's having to set up the network and being able to configure
it.
NEW SPEAKER: And part of the problem is, if we're, you know, dealing with not
only just sort of islands of entire price environments it is also carrier
environments.
AUDIENCE MEMBER: Well, I work for a carrier and I understand this completely.
Right. But the problem there is that the people in the carrier environments tend
to think of I S 4 one where it's one big protocol that does everything. Not how
IP works. There are particular protocols that do particular things and if you're
talking about configuration, there are protocols that do that. And if something
has to be changed in order to have conductivity. Then change it in that
particular place.
NEW SPEAKER: Let's move on. You've made your point.
NEW SPEAKER: Let's move on.
NEW SPEAKER: Just to be clear, the point is that SIP is not delivering con
configuration.
That's another thing, SIP is used for discovery and event notification.
NEW SPEAKER: I have a feeling that we have gone through this discussion
something like two years or a year ago, on the mailing list, and as far as I
remember a correctly, resulted in well, don't do this in SIP. So, apparently, we
must have new point OS the table that warrant a re visiting.
NEW SPEAKER: Actually, I think Brian, unintentionally killed this one last time.
So my recollection from the list was that it was not killed and it was forked
off into a separate mailing list.
NEW SPEAKER: Yes.
NEW SPEAKER: It was a priority issue and you know, the group was too busy at the
time.
NEW SPEAKER: Okay.
NEW SPEAKER: This was the impression I had from going on. And so, if there's not
anything new, --
NEW SPEAKER: I think I can, since I've, since everybody is partial I'm
responsible for partially starting some of this mess. Because we started looking
at, what made this difficult initially was that the aspects which you have now
somewhat diseven tank Gselld got in first, which meant basically, the whole
discussion, that SIP became a data transfer protocol, which is where people
objected and this is exactly where the previous slides were trying to address on
the second, first and third item. So I think we're ahead of that tech status.
So, we, the idea is, do you have now more cleanly separated this into components
which are data retrieval and access type of issues and discovery and
notification issues that we didn't have last round.
NEW SPEAKER: And I have one further question regarding your list on the next
slide, and where you were speaking about roaming users, were you envisions that
when I travel to Australia and my SIP phone would automatically get updated from
home when I have a configuration change there? This would be why you would be
needing a user location, actually, I might not be liking this, but that's
NEW SPEAKER: That's your privilege.
NEW SPEAKER: Yes. You know,
(Several people talking.)
NEW SPEAKER: You just travel without your device.
NEW SPEAKER: Okay. This wasn't clear.
NEW SPEAKER: I admit the requirements on the roaming were not spelled out in the
original draft, which, you know, there was another issue here, is that
requirements expire, and I don't think that's well identified, you know, the
roaming requirement.
NEW SPEAKER: I think one of the key items, the since the last discussion of this
too, was with a bunch of us gone, said S M does not meet all of our provision
requirements all the time. So there's a bunch of people who want an alternative
to that. And that's one of the decisions that have been made since the last time
we went through this had whole thing.
NEW SPEAKER: Well, I think that would be a hard one to, you have to make that
case. The management areas is already looking at this question and last time, it
would be necessary to make the case, a different management protocol was needed.
Also, this looks like it goes down a path of kind of breaking the first
paragraph of the events draft. Because, it's using the notification for things
which are not about the sessions, and which potentially could get much broader
than the maybe fairly well narrowed suggestions that you're making here.
But it does affect
NEW SPEAKER: It does affect --
AUDIENCE MEMBER: It affects the session and it's not of the sessions.
Configuration is not necessarily the whole part with SIP's operations directly.
And I rely -- well, you are actually. It's not clear, anyway, the management
area is taking a look, and this group is a filtering group. So you really have
to apply some hard questions in filtering on things like this. And I appreciate
that there, I think there needs to be more discussion of some of the assumptions
here and some of the possible out comes of taking this work, and I would not
support it on this basis.
NEW SPEAKER: I do think that it does raise a discussion of why, a discussion as
to whether the existing configuration mechanisms, and the ideas that you
mentioned, I think that's basically a no go area at this point, for anything
more complicated than a single address. But A cap had a tremendous amount of
success, to put it lightly. And others, as to what's going on in the area. As
you seed, said, I think you should look at this as an incentive, to see, is
there reason why this is coming up? And I suspect it is because the existing
tools that we have in our toolbox aren't particularly suitable. But I don't
think this is just a SIP issue, because as I said, if we do it well, even
outside the SIP context, this notion, clearly there's a need for that, because
we have a lot of other things which we can't configure well, which people have
doubts that just running S N M P is the correct approach.
NEW SPEAKER: The S M P effort just got a re start, with expertise present and
there are a number of features that were not in the MIF to date and there's a
lot of something like the tracks and so forth that might be absorbed more now
that stuff has settled down. So I don't think you can write off S M M P. Without
a really good case about why it doesn't serve the purpose.
NEW SPEAKER: I'm going to rule this particular discussion out of order. We're
not talking about the mechanism for dealing with configuration. I think the only
question that we have to talk about here is whether there's anything to do in
SIPPING, having to do with generalizing the notion of registration, beyond
maintaining sessions. That itself could be declared out of scope for SIPPING
because it doesn't apply to sessions. That's a reasonable discussion.
I mean, what protocol should be used for configuration is not on the table.
(Several people talking.)
NEW SPEAKER: Nothing would prevent anybody from using the same framework to say,
to tell the phone, here, go use this, this is how to set your traps, this is
your booth strapping S M P configuration. That's a delivery mechanism. And you
know, that's, NCAP, you can easily encapsulate that mechanism as you could any
other one.
NEW SPEAKER: I think the questions, if you decide to take this to a working
group item, you're doing a job of a applying the SIPPING filter today.
NEW SPEAKER: Right.
NEW SPEAKER: And the SIPPING filter applies to the general architecture too so
it's not out of reason to talk about that.
NEW SPEAKER: Okay. So it seems to me, the only case that's been made today is
whether or not there's any argument for having a discussion in SIPPING on
requirements for generalizing the notion of registration, to cover things beyond
maintaining sessions. If that in itself is beyond SIPPING, the charter SIPPING,
then we can't even have that discussion.
NEW SPEAKER: You'll have a draft about that topic. You have a draft about doing
--
NEW SPEAKER: That's what the draft talks about
(Several people talking.)
NEW SPEAKER: The draft does not talk about configuration.
NEW SPEAKER: Well, I mean I read it to talk about configuration. Certainly it
can talk about configuration.
NEW SPEAKER: So
(Several people talking.)
NEW SPEAKER: Clearly, this is a very rocky subject. Do you have one more
comment? Make it quick, please.
NEW SPEAKER: The last thing you said, do you want to configure the fire wall
travelers on the SIP phone? What is the last bullet.
NEW SPEAKER: The point is, and it's one of the reason that we, that we also, we
have to get the, these, it's a requirement. Whatever we use, we have to be able
to use this for a SIP user agent that's behind the fire wall, on the inside of
the fire wall, whether the configuration is outside. And so the thought is,
well, we already have to solve a SIP problem there. And it just makes it a
little easier, to be able to get notifications for the end point for
configurations.
NEW SPEAKER: You wouldn't actually contact the public at a certain point?
NEW SPEAKER: Sorry.
NEW SPEAKER: You want to contact the public on the phone?
NEW SPEAKER: No.
NEW SPEAKER: All right. I don't even know how to bring this forward, but at the
very least, this discussion, if there's anything to be had here, but obviously,
we're in rocky shoals completely. I guess I really would like to know if this is
a minority interest, a minority get it out of here or whatever. So, again, I'll
call for a hum. Is there interest in continuing discussion, not of
configuration, of how you do configuration, but of the two issues that were
raised as properly said? Does the room believe, independent of whether we end up
clearing it out of scope period, is there interest in participating in pursuing
it? Can I have a hum for interest?
Okay. Can I have a hum for people who think this is completely out, we should
not be talking about it. Thank you.
( The first one was louder. )
NEW SPEAKER: John.
NEW SPEAKER:
NEW SPEAKER: This is specifically, I think that there's been a problem with
folks not understanding what his draft is about. Which is about notifying,
notifying a user agent that the configuration for a user has changed. The user
profile for a user has changed.
NEW SPEAKER: Hi. It's louder than I thought.
For some reason, I was asked to come to talk about this tell URL outlook, that
is going on right now. Although I'm not responsible for much of it, actually.
As many of you probably know. The tell URL is part of how the SIP URL is defined
in R C 2543 BIS, that is insofar as it can be a user portion of a SIP U R I. So
SIP has a tendency, and I guess as it turns out, the definition of the tell URL,
definitely had some other goals than providing functions that we needed for SIP.
And I guess it came out of some other work initially.
In light of that, Henning has generously volunteered to secure work on BIS R C
28 O six. And that has gone through a couple of conditions already. And this is
basically going to clarify how the tell URL works, what kinds of things are
expressed, and actually try to remove as much as we can of the unneeded
functionality that's left over from some previous ideas about how it worked.
There's also two drafts that are out there today, that are by a colleague of
mine, James Hugh that are associated with a number of specifics. And these
drafts provide a couple of extensions to the tell URL, to allow it to express a
little bit more information that is necessary in order to do a number of port
ability. And the second of these drafts provides some sort of motivation and
general cases about how it's used.
I also had a graph that I just put out that is very brief, that provides an
extension to the tell URL to have the calling C P C parameter, that would be
available and something to express in a tell URL. Basically, since none of this
work is actually taking place under the auspices of SIPPING, but SIPPING is a
community that would have interest, and together, we thought we'd thought we'd
put up a brief advertisement for this sort of stuff.
It may be the case this this is no longer home with us. And I may go to another
group and become a charter.
NEW SPEAKER: They're basically trying to close down.
( He named the group I didn't hear. )
NEW SPEAKER: So, it's not settled.
NEW SPEAKER: Since I'm doing one of the documents, just, one sentence on, there
have been major changes to the 28 O six BIS, in the sense that it is much slim
err now. So I haven't heard much comment on it. You can look at it. If you look
at 28 O six. Don't seem it's minor. If you don't like it, scream soon.
NEW SPEAKER: For example, the fax URL is gone.
NEW SPEAKER: Because we were enable to find anybody who needs it, has
implemented it.
NEW SPEAKER: This is a somewhat unusual, in the sense that this is far behind
the requirements phase, this is work looking for home. And in this case, I was
trying to follow the procedure as to basically moving it on. So this is
hopefully, we can, I can get through this without getting -- let me talk about
the, because, there's somewhat of a process issue, generally speaking.
So, requirements for what this work started out is, to establish preferential,
actually less than preferential, if you want that as a word, preferential
treatment for SIP sessions when computing for destination U A resources.
Emphasis U A resource is not something resources. Typically, those are things
living on IP telephone gate waist, not necessarily public networks but private
as well. Usually represent multi layer priority scheme types of things, that are
involved but could theoretically just be resources on the Gateway itself,
appliance, and so it doesn't have to go into a classic e-mail.
There is a SIP priority header as discussed, this is different use as primary
intent is not to deal with resources on the communication side, but resources on
the recipient human side.
This draft has been, it's been short, just a few pages, there have been a few
changes since last time, which I won't go through in detail here. There's been a
space priority division. A space definition and a clear definition of default
behavior in the case of what happens if you get something you don't know, with
the overall goal of maximizing completion and rejecting calls which you should.
There's a definition of error behavior and that's open. That's a detail
discussion issue.
Open issue, which is basically at this point a process question, namely, this
has gone on without being a working group item, either SIP or SIPPING. For quite
a while, with a lot of mailing list discussion, with apparently mailing list
discussion and on the SIP list, and on an individual e-mail as well as on the I
E prep list. So I believe the current draft, which will be appearing after the
black out dates for, as reflected all those comments that I've received, so the
question is now is, where does this go? Is this something which should move --
I'm sorry. I didn't see you.
NEW SPEAKER: I'm waiting for you to finish your ramble.
I think it's a reasonable question. But I think it's too early to ask the
question. I E prep is just starting up, and it would be useful to answer a
question after it's been asked. I think I E prep needs to come up with some idea
of what it thinks it needs on a functionality like this before we define
functionality, hopefully, that wouldn't take very long. But I think I E prep
needs to put in requirements before we finalize this.
NEW SPEAKER: Okay. So you should test basically, ahor a holding pattern.
NEW SPEAKER: And you of course, can go in there and insight the masses for I E
prep.
NEW SPEAKER: Okay. Thank you.
NEW SPEAKER: Basically, it's I checked my e-mail this morning, and you know,
there is a priority header in the e-mail, which kind of applies to something
like what you are describing as making some e-mail going only to the user that
he can know what you're doing. Now, out of the e-mail in my mailbox, the only
ones, there were two of them that had this header set, and one was about how to
make money when you sleep, and the other one was how to get larger something.
And, so there is a real problem with something, which is all the privacy and
other requirements. And unless we define that clearly, I don't see much value in
going forward.
NEW SPEAKER: Are you saying that the specific security considerations this this
draft are in issue?
NEW SPEAKER: I'm saying, that unless we understand, --
NEW SPEAKER: There is a security consideration this in this draft.
NEW SPEAKER: But I don't think it's sufficient.
NEW SPEAKER: Good, okay.
NEW SPEAKER: Can you make concise comments.
NEW SPEAKER: I look forward to your --
NEW SPEAKER: I was talking, one, Scott, are you basing this on, only on I E
prep? Because that was mostly what your comment was. This should find a home
until I E prep defines the requirement. I would submit that there are several
networks existing today that would need this interfacing to circuit switch
network.
NEW SPEAKER: Well, that's part of the question, is what functions are needed to
interface with the circuit switch network, and I think it's not a question of
whether it's finding a home, it's a question of whether it is finished. I E prep
may look at it and say it's othogonal enough and I don't care. But let's have
the
NEW SPEAKER: {e} prep discussion first.
( O T H A G N O L. )
NEW SPEAKER: You keep saying there's just an end user. There may also be some
network requirements for this. Who can, it doesn't matter if you want priorities
to go through, that might be some user looking at the network.
NEW SPEAKER: Okay. Just send me that by e-mail, in case I miss it. Okay.
Anything else? I'll do the next one.
The next one is, again, a, more, this has been going on technical work for quite
a while, on, and there have been Bob on this for Salt Lake City for example, and
the question is, where did this go? This is just a summary of the current state
in one slide, basically, it's a definition of a specific user name caller S O S.
And the URL of the local, the address of records domain, plus definitions of
various S O S start specific things, which are then possibly used to invoke
emergency services. These are not I A prep services so this is not emergency
prepare Edness it's one one two and one style services. And this would indeed
initiate appropriate routing to the local emergency call center, whoever that
happens to be.
What is out of scope is, which is discussed, at length on the mailing list, is
service behavior, so caller initiation, disconnect, all that stuff. Out of scope
is finally, of this draft, is finding the appropriate emergency call center, for
a variety of reasons, even though there's ongoing work on that. It's out of
scope of this draft, because it's likely to be country specific because of
existing infrastructure. However, it is a sub issue or a SIP issue, depending on
how, because I believe that in order to achieve inter operability in a way that
makes proxy behavior predictable, it has to be codified. For example, the U A
and user information, some of the stuff that really lie currently on the ISDN,
we need to delegate to the U A, but the U A needs to know what that is and what
it needs to do. So it needs to recognize that as being special and secondly, it
needs to possibly use this for any type of voluntary
NEW SPEAKER: Burt somebody, come up if you're around.
NEW SPEAKER: So, it is necessary to do something like that, otherwise, we'll
have lots of different faulty stuff like that, identifiers like that, getting
accidentally assigned to somebody else, which later then causes problems. So I'm
particularly reluctant to punt this for a number of years, because at that
point, the issues which are relatively trivial now, may become much more of a
backwards compatible issue.
To go forward, my proposal is to fit it as a best current practice, because it's
not a protocol extension in any particular way. It's an operational procedure
within this. Unlike, from the service U I discussion, agreement is necessary and
very helpful, and business formerly being coordinated with the North American
emergency number association so they're aware of this going on. And I believe
that the draft itself has undergone sufficient comment that actually the content
is now more or less ready except for a missing I N A consideration section.
NEW SPEAKER: So I'd be happy to see a best current practice saying S O S is a
preserved order or something. But I'm dubious about going forward to a partial
solution. Because then vendors will say we have 911 and people will think it
works with something. I think we shouldn't do this until we have the whole
package.
NEW SPEAKER: Well, if we can discuss that, my concern is that this might be the
common subset that we can actually do without getting into jurisdiction specific
issues, and I've been involved at a fairly intensive level, with the 911
community and it unlikely that we can do much more than that that. And I'm
worried about having this broad idea of reforming the emergency call services
and missing the opportunity.
NEW SPEAKER: Quick, please.
NEW SPEAKER: I suggest you do not use the equal S O S, because it has baggage. I
suggest you should use things like may day or com com which is referring to the
classic call codes.
NEW SPEAKER: Let's take that particular issue to the list. Can I have a hum for
people who would like to take this as a B C P, this is a convention, right?
( Humming. )
NEW SPEAKER: Opposed?
( Silence. )
NEW SPEAKER: Okay. Let's do it.
NEW SPEAKER: I'd like to take this opportunity to ask for the progress of the
blue sheet. Hold it up, please. Who has it? Do you have it?
NEW SPEAKER: We didn't get it at all.
NEW SPEAKER: Where is the other one. Who has the other clipboard. Great, bring
it up please.
NEW SPEAKER: All right. I'm Burt, somebody, and myself and my co-authors, put
together a few slides to try to drive this notion of key events.
One point is, the need we see that applications servers need to receive
something, and that's independent of the media path, and in some cases outside
the SIP path established.
An observation is that an independent media path for current R T P, specifically
R T P '83, and the question of we post are the R T P based solutions suitable
for transporting a synchronous activity outside. Something.
Our conjecture is that no, the U I As are transported at a single time, with a
number of messages and the band width is critical. The liabilities. It's not
desirable. And in this case, the user application, it's not a requirement, and
we feel liability of the information can be achieved by message delivery
acknowledgement.
And last point here is that these U A Is should only be generated when
specifically asked for by an application.
Then, corresponding question, is the transport of the something user activity
sufficient for future user application interaction? And another point, our
position is that no, it's not, and we don't want to limit the future user
application interaction to only using the telephone key pads. We would like to
see a generic keyboard, slash device, specific for support.
In conclusion, as far as this goes, end to end synchronous user activity
indication, have different functional and performance requirements and some of
the requirements that we see, the need for a separate mechanism.
We feel new a synchronous user activity passport mechanism is needed to generate
these indications outside of the media plane so that indications are only
generated on request and sensitive to demand signals.
If we put together a few set of requirements, that we think are applied to this
key based or button based user activity. User indications. First one being is
that the use indications to the network elements participating in the sessions,
are independent from the session media.
We think the needs support for user indication be key buttons. And another
requirement would be that another entity desiring user indications must be able
to request the user indications from another user. If you're receiving the
request, you must be able to respond with willingness to transmit these user
indications.
We can discuss the mechanism over the network with a single path requesting and
receiving requests independent from each other. We see the separation between
the transport mechanism and the signal plane and the message syntax is required.
We review the mechanism and it must be able to support filtering so only
indications of interest are transmitted. Mechanism must support reliable
delivery, at least as good as the session control protocol.
There are a few more, the mechanism must support the device input inside and
outside of the established session. Mechanism must support device of user
interfaces and determine the make and content of the user interface.
The mechanism should support the device and specific user buttons. And the
mechanism must support some sort of key restoration. Some form of, or indication
of relative key press start time, as far as when there's a sequence of these
events.
The mechanism must allow for security, slash privacy, resource, both entities
ought to be able to authenticate each other.
To summarize, there's a couple of proposals in this area. The signal needed is,
transports the R F C 28 three three, something about the info in sub note.
There's a draft myself and a couple others coauthord for transporting these key
events.
Now, we start discussing this. Should the mechanism be, it seems that there is a
strong desire for some kind of mechanism.
NEW SPEAKER: The question I have is, when the session is being set up, does the
called party somehow know that the capabilities of the calling party is to do
advance signaling through 28 three three, or through signaling path, to let,
because the called party, subscribed to these events --
NEW SPEAKER: Getting into mechanism. What's the requirement?
NEW SPEAKER: Well, the reason here is because we say we don't support
unsolicited events unsolicited notifies, so if we don't support that, to call
the body that he subscribed, there's a specific thing that you have to subscribe
to those events.
NEW SPEAKER: Yes, that's an assumption for, the kind of applications for the,
you know, that require these kind of service, that the, the calling party will
--
NEW SPEAKER: So if you require the calling party to subscribe, you have to
somehow have a new requirement to tell the calling party what events you have --
NEW SPEAKER: The one proposal, now, if you're going to use R T P, you can do
that in SDP. As far as our proposal, --
NEW SPEAKER: Consider P has no mechanism for signaling path. I mean, --
NEW SPEAKER: I understand, you know, and I if there's a change to the
requirements, we should get them into the requirements.
NEW SPEAKER: I have a slight concern as in the draft, as the requirements are
stated, that the events that are we're talking about are very, very physical.
Very close to, you know, a physical device, a third but a certain button is
pressed and most of these problems can be better solved at something with a
higher level, or some kind of application level concept of what a user is trying
to tell me.
I don't, unfortunately, I don't, I'm afraid my expression is not as clear as it
could be. But I'll use the example of D T MS, where many devices, I get an E T
MS from it, that device, doesn't necessarily indicate that I pressed that button
for that long. That may indicate that I ran some script, that through tones at
me. It may, you know, I hit a button and it controls it. The D T M F,
supposedly, tells me that the user expressed some desire to do something. Which
is a higher level than the user pushing a button.
NEW SPEAKER: User something
NEW SPEAKER: Great.
AUDIENCE MEMBER: The example I had was, let's say we're playing a video game,
and what I want to express that I hit the four K, three times and then the 5
key, or what I want to express is that I wanted to turn left twice and shoot.
NEW SPEAKER: Okay.
AUDIENCE MEMBER: I hope you're using SIP for that.
NEW SPEAKER: I don't know what order. Let's take him and then him.
NEW SPEAKER: So, personally, I feel like that, I sort of was reluctant to, I was
reluctant to to say that I agree that there were some scenarios that we might
want to do this in the legacy case. So I offered this signal, this draft, with
sort of that in mind and I came up with three cases where, you know, that might
be a semi reasonable thing to do. I will be the first person to admit that, you
know, it might not be the cleanest thing to do. For the case of just sort of
more generic, just kind of generic key press that's not associated with any
legacy, with any tones or signal digits. My opinion is that this is something
which is better suited through, you know, using some, asking the client to
execute or to interpret some kind of mark up. And then returning, you know, a
high level of the sort that Ben described. What was the semantics of this? You
know, I'm not sending, the A T or the up arrow key, I'm sending the shoot now,
or turn left. Or you know, whatever it is.
NEW SPEAKER: Dave.
AUDIENCE MEMBER: So I agree with what he said over there. But I wanted to
address question No. 2, whether the SIP framework is appropriate, with another
question. Which is, and we've seen this in the I M context as well, which is, is
the actual usage scenario for something like this going to be hurt by a stop and
wait protocol?
NEW SPEAKER: In other words, A CT P for example?
AUDIENCE MEMBER: Well, SIP events notify stop and wait protocol. So, an
interesting question is if I'm punching but buttons, is this stop and wait
pipeline sufficient to do what you actually want to do. And I don't know the
answer one way or the other.
NEW SPEAKER: Okay. With regard to the application, specific stimulus is what I
see it as, the way that this was addressing, where rather than looking at the
key events, you should look at the application functions. I don't believe that's
a good idea, how can every single device know about the shoot or any clip of
application action, not to say that you don't necessarily want to have access to
these high level functions, but it raises a huge number of other problems. First
of all, you have the device now has to support all the different applications.
It has to know which request an application is for. Because different
applications might have mapping between internal pulsing and different mapping
and different application level actions.
On another approach would be that this is looked at as a simply an application
specific stimulus, whereby an application request that requests if the device
knows about certain applications action run, in which case the application can
use those application specific stimulus, rather than the face keys, so that in
that way, there might be perhaps some trade off, when the device knows about the
application, and the application can also use that device when the device has no
knowledge of that application.
And this is actually designed, that although very interesting keys here, I
believe that whatever mechanism we come up with should be more general or more
exstensible, than just addressing the case of what the keys are and that would
be a starting point, I believe.
NEW SPEAKER: Looking at the, or staying at the basic key events for a moment.
I'm remind of mega phone profiles but even worse, giving a broad definition,
protocols such as X or E N C or T-1 28, I'm wondering what the next step would
be to define something like draw a circle, draw a square, fill the background or
something like that, on SIP events and we should be careful not to go down that
road.
NEW SPEAKER: Thank you.
NEW SPEAKER: I guess I should make two remarks. Really, the first one is that
there really are two sets of requirements. One has to do with delivery. And the
other has to do with content, which is, you know, how to express the content.
And they should be dealt with separately, because the delivery requirements
really determine your transport mechanism. Things like, s multiple agencies
being able to receive these things or subscribe to them or whatever, is a
delivery requirement.
The other remark is that you ought to address this business of, the double
nature of the stimuli, fundamentally, you're in a contradiction here. SIP is an
application level signaling medium. So, presumably, you've got an application
able to filter things and give meaning to them. Of course, that implies
application level event packages I guess, to go along with it.
But if you're really dealing with the keys as stimuli, yes, we have M X G, to,
for user interface control, and it would seem more reasonable that you use
something like code to pick up the stimuli and then interpret it through your
application as doing your SIP or whatever, for delivery elsewhere.
NEW SPEAKER: I think this raises a question of whether we want to get into, in
SIP, the notion of device proceed filing and whether we want to make that
something that we deal with. If we don't, we want to stay far away from this
kind of notion unless we limit ourselves to saying, okay, all SIP devices have a
key pad, but I'm not sure that we can even say that. This notion of proceed
filing, I think an important one. We want to tackle that or do we want to leave
it alone and use some other mechanism or not adopt some other standard?
NEW SPEAKER: So, I just want to make a quick comment on Robert's comments,
that it may be difficult to sort of know what, you know, what the semantics are
of this other high level application thing. I think that's one of the beauties
of mark up, is that it allows you to, I can send HTML to the phone, it if
supports it and I can create a form or link or whatever. And the phone doesn't
need to know all the semantics. It just has to interpret the mark up.
NEW SPEAKER: He stole most of what I was going to say. I'm waffling this issue
and particularly, actually, I do think that a mark up approach is probably far
better. Because the features are action able, where you're saying, I can have
multiple things, all list tending for key event, but how does the user make
sense of which ones to send it to and how the applications interact with each
other. That gets complicated. When you have mark up, that allows for, that
allows for allowing the user to render, allows them to make it non ambiguous.
And again, thinking more broadly about stimulus, we've had, you know, I've
actually viewed the web as a stimulus protocol. And the fact that it was much
more general purpose, and with this concept of presenting a user mark up with a
stimulus based on that mark up has been determined to be issue dependent. We
would like to have a stimulus model that allows for HTML, but to support more D
T M F only kind of mark up. And certainly voice X M L is another thing. In fact,
I know of people who make telephones that actually look at the voice X M L. And
use it to generate stimulus applications to the network. You know, so, we've
already got some presence for doing that kind of thing and I think that might be
the better direction.
NEW SPEAKER: These two and we're done.
NEW SPEAKER: I want to elaborate on that point a bit. There may not be a human
at the U A. If you don't bring semantics to the user agent, you eliminate the
ability for any sort of application to affect that.
NEW SPEAKER: Next.
NEW SPEAKER: As for any mark up, well, first of all, HTML is a mechanism we
still need requirements here, but addressing that, if you can do the current
multiple with mark up, in my mind, does not provide the level of two directional
transfer of information as in the application determining what a device
possesses, and vice versa. It's more of a one directional flow. And that's
great, if you can come up with a user protocol that addresses all the
requirements, that, that's great. But, I don't believe it will.
NEW SPEAKER: Okay. I'd like to see a hum for people who are interested in the
subject of its mark up or key press. I suspect there's a lot of interest. But I
want to hear it. Provide some kind of mechanism, please hum.
NEW SPEAKER: I don't even have to ask whether there's any opposed.
All right. What I've heard is, we have a proposal on the table that talks about
NEW SPEAKER: Sometime in the next month or so, 30 days, I'd like to see a
requirements document prepared by those who would like to do an alternate
mechanism or an alternate approach. It's a different set of requirements.
Okay. If we get such a thing, we can consider which one is a better one. If not,
I want to move this thing along. So okay. Seem like a deal? If you want to
change the requirements, make it more general or more mark up like, whatever,
fine, get those out on the table. Let's discuss them. Otherwise, I don't want to
come back next meeting, and have this thing still kicking around without any
direction.
NEW SPEAKER: All right. Talk briefly about published requirements. Hopefully,
we can get into a discussion before we run out of time today. I'll be surprised
if we finish.
We have two drafts talking about publish right now, that have been submitted.
One is Donovan's draft and the other is hectors. As an up load of service data,
into a service running in the network, site CPL and presence as the kind of data
you want to push. It starts a discussion on whether a SIP should be used or
whether SIP should be coupled to a companion protocol to achieve the goal and
lists requirements for an extension if SIP was chosen to move this information
around.
Okay. The requirements draft, the you can push content, explicitly bounding push
to the service, you told the service what you wanted to be done with this
content as part of the push. Made use of authorization and authentication, and
that the contents could have a lifetime associated with them. That lifetime
could be M. Brian put together a proposed method that satisfied these
requirements. The method they elected was the push carrying contents, in bound
things with ahead err and you told the service what you wanted to do with that
information with another header. And we went through these things in London. We
had very little discussion, which for many people was
interpreted as little optimization.
But very little support for the requirements in that draft. Which probably means
that the requirements that are captured in Donovan's draft are not in fact what
we want.
So where is the disconnect? The big one is, an argument on whether or not it's
going to be appropriate to meet the requirements of pushing information to
services, inside of SIP, or if we want to do that with another protocol and
coupled with SIP?
How can we quickly get to closing that issue? One of the first things that we
should do is look at the requirements that are stated in the Donovan published
requirements draft. Restate them without making the assumption that any
particular protocol is going to be the substrate, and see if there's still the
right requirements.
If we do in fact choose another protocol, it's pretty clear from the ordinance
that's in the draft, and arguments that we've already had, what the issues are
going to be publishing inside of SIP, actually using a SIP mechanism for
publishing.
If we choose some other protocol, H T T P or something else, how do you bind foo
things to SIP things. If I have an H T T P name that I'm publishing to, how do I
correlate those two things? At run time, in the infrastructure, if I'm
publishing with HTML, how do I make sure that that HTML gets to the thing that
is responsible for the SIP thing that this publish is supposed to influence?
So, with that, I'd like to open the floor to discussion about whether or not
we've captured the right set of requirements on publishing? Do we think publish
is something that we need to address as a standards? Is there something that we
need a standard solution for? The ability to push a presence document into the
network
( There's a lot of feedback on the Mike. )
I'm standing under a speaker or something.
NEW SPEAKER: And does it need to be general? Would it be sufficient to have a
specific C P O publishing mechanism, a specific publishing presence mechanism
solve whatever other publishing problem came up, with another mechanism or do we
want a general mechanism?
NEW SPEAKER: I would just make, while this is a publishing mechanism, I would
see this as slightly different, in the sense that we need a mechanism that we
need, in a fashion, that would associate data with SIP type of things. I'm not
likely to call it a publishing mechanism, because that implies a mechanism as
instead of requirement. So we need a way to associate that and discuss how, I'm
worried about punting it, because it leaves out, if we don't do something,
reasonable in that, even if it's not the only answer, it means that our
architecture is very incomplete and basically defeats the inter operability that
we're trying to achieve.
NEW SPEAKER: Whether we're talking about publisher or not, we need to address
what you're doing in other protocols and --
NEW SPEAKER: Yes, that's actually the more important part. Because we have
several means, I mean, we can probably all relatively quickly agree on how do we
get data from A to B or we don't have to necessarily all agree on it.
NEW SPEAKER: So I think this is actually really illustrative and we should get
right to the point and say, what are the kind of issues that would help us
decide whether or not there's stuff that needs to be said.
Another one that's worth thinking about is who needs to get the information? For
example, and this is actually very important, if you look at a presence
document, okay, that I want to up load into the network. Who needs to see it?
Does it need to be be one server or many servers? So if you have a server form
for example, that information actually needs to be known by every single server,
that would possibly be serving my presence for subscribers, right, in the
scenario. So the requirement is that that information be made available to
reliably, a large number or more than one unit and that's not even something we,
you know, forking isn't even meant to do that.
So, it's already clear that SIP alone, at least is not certainly going to be
sufficient for that. And that's true for other things like CPL scripts. For that
it's got to go to every single server or available to every server that might
want to do something with it. So I think that kind of information is helpful.
NEW SPEAKER: But that's clearly, we have that problem implicitly, in the sense
that registration --
NEW SPEAKER: Registration has the same problem. True, true.
NEW SPEAKER: So I mean, my concern is that,
NEW SPEAKER: All right.
NEW SPEAKER: I don't want to solve the general reliable distribution of data
across the Internet problem until we can have CPL documents published.
NEW SPEAKER: Right. I agree. I agree. You're absolutely right about register.
So, okay. Maybe that's just a moot point then.
NEW SPEAKER: And I have a very skeptical that there is such a thing as
generate data up load requirement. Because you don't, you almost never up load a
piece of data in general. You have in most cases to obtain an existing document
that has some syntax. You may have to research something. So in most cases,
you're going to do an operation of some kind in the network.
Now, if you do that, I know of two models. You can have something like a
generate P C or you can have something like a generate A T and X N M. So two
models have been presented. Okay. And, your draft is very short on what we want
this up load to be. And you give two examples. Up load CPL and up load this
presence information.
I don't know much about CPL, but I definitely know that up load presence
information is by no means still. Because the presence sample is likely to merge
from a variety of sources. So it's never the case that you just take a document
and up load. So I'm very skeptical that there's a general data up load
requirement.
NEW SPEAKER: Is there anybody that will take exception with that? Or do we just
declare that solving this problem in general, is something we don't want to do?
The up load part, not the finding. I think we have agreement that we need to
address binding with other protocols. But is there anybody that disagrees that
the generalization of pushing data up to services is pointless? that we should
instead focus on application specific mechanisms each time an application a
risees?
NEW SPEAKER: Nobody is running up to the Mike. That sounds like direction to
focus on application specific solutions.
NEW SPEAKER: Yes, yes. But I like the, coming up with the association.
NEW SPEAKER: Right.
NEW SPEAKER: So, I think the direction then is to come back, we'll find somebody
to own the association part. Go ahead.
NEW SPEAKER: Actually, this is not necessarily my opinion, but I heard people
that said we should do it generically and other people said the opposite. So I'm
not sure that no one ran up to the Mike to --
NEW SPEAKER: All right.
NEW SPEAKER: Do you want a hum?
NEW SPEAKER: So, I mean, I'll address that. I think the purpose of SIPPING is to
look at those problems exactly. So, we should start with what we know and then
look to see if there's common requirements. So maybe, it makes sense to look at
what is specific about presence and what's specific about CPL, rather than
saying we need a generic manipulation. So there's the story.
NEW SPEAKER: The start is to on the association.
NEW SPEAKER: I think those are several. They are parallel, because they're
different problems.
NEW SPEAKER: Right.
NEW SPEAKER: I apologize for not running up to the Mike, I didn't want to talk
too much. But I think in general when you do this sort of thing, data needs to
be transferred. Whether it's merged at the server end or up loaded as a whole,
it's done on an application basis. It's useful to have a generic mechanism by
which you transfer that data and how you handle it is up to the application and
server itself.
NEW SPEAKER: Okay. Well, I think separation, finding somebody to own the
association is important. Can we have a volunteer for that? That would be great.
And we can now figure that out.
NEW SPEAKER: That's something that's going to be, building the requirements
(Several people talking.)
NEW SPEAKER: And we need a requirement process for that. If people want to work
on some generality of up loading CPL and up loading presence, and see whether
there's something to be made out of that, fine, but I don't see it yet.
NEW SPEAKER: All right. And in the better late than never category, we got the
blue sheets. If somebody has not signed them, please come up front. Something
about the kick off is Wednesday in the room called D E L U T H.
Updated 28 Mar 2002 01:19:49 -0600