IETF
Session Initiation Proposal Investigation WG


NEW SPEAKER: we are going to get started.  Hello?  We are going to get
started.  Please -- -- we are going to get the meeting started, Adam,
I was going to page you.  We're going to be needing a note taker----so
two of them, Dean -- -- thank you very much.  So this is the agenda
today.  We have Adam going to be talking about the completion service,
and the call will talk about offer answer usage and then we will have
race conditions -- -- any comments on the agenda?  Okay, Adam is up.

NEW SPEAKER: and I just, let me talk really quickly about the
configuration framework.  Just for your information, we just had a
meeting among the editors of the draft and a few people that were
reviewing the draft, so the completion, the draft is going to be
rewritten just for clarity.  So we will restructure the whole draft
and keep it will actually take a stab at the initial structure for the
draft and will be sending it for comments, and we will be getting one
or two extra editors to implement the structure and have a new draft
hopefully soon.

NEW SPEAKER: this is good enough?  Okay, thanks.  So, put together a
draft really quick on basically an alternate mechanism for affecting
the call completion draft -- -- that was brought in here couple
meetings ago.  A quick overview.  It uses the requirements and
satisfied the requirements presented in the earlier documents.  It
uses normal set option tag mechanism to negotiate support for and
activation of this extension.  It uses BS CPU, which hopefully -- --
basically took place in requests for activation to callback service
within a queue and to manipulate the queue to be able to pause and one
cause, because those are some of the harder requirements that were
actually in the document.  It uses, RFC 3087 techniques basically
whereby it a URL that I am handing out is enough indication to me as
to what is supposed to happen when it comes back.  In order to
prioritize these completion calls -- -- and to correlate, who the
caller is relative to the requests that they put in the BFCP to
earlier.  So far, the review back that I have received has been
strongly in favor of this kind of solution, although not unanimously
and of course a lot of comments on the specifics.

So why BFCP?  The big reason is because the semantics that were in the
earlier documents required exactly the ability I was talking about a
couple minutes ago that you can cause and one pause requests and we
don't really have methods in sip to do this right now.  One of the
problem, I thought you really need a separate protocol for these sorts
of things and it is really good at setting up sessions of protocol to
make it happen in a closer investigation.  The problem is similar to
people waiting in line to use the floor at a conference.  So BF CP
seemed a very good fit, because the problem seemed congruent.  So, I
put together a number of issues that people have raised about the
existing documents so far.  And I'm going to go through them briefly,
if people want to (inaudible) well, Tommy overall think this would be
the time.  The first thing is it's actually conveying to you our eyes,
when you look at the way the draft is a setup you have three faces.
There is a call failure, either the busy or giving up on a ringing
phone situation.  Then there is the setup of the BFCP itself.  And you
need to have a way to figure out which you are I you are going to send
that too.  And finally when you are granted permission to talk to the
remote party, there is a third invite.  That is set up the actual
voice call or session.  And I need to somehow to convey that URI.  The
draft rightness as it would go back and forth, but it is not very good
semantic match and we actually have an issue with the decomposition of
the servers from user agents.  So basically, what the server stuff we
have a separate server providing this and the way that the graph is
working right now is because of the mechanism it uses to cope with
forking, you can actually have a third party other than, not party, a
third server other than the user agent you are calling to perform the
BFCP queue maintenance.  That's the way that this works is that the
proxy does the server and the callee -- -- and the surfer thing is
actually going to be holding on to the BFC queue for you -- -- and
this is the thing right now, it said -- -- and it sent back an error
response basically in the forking proxy will close this lady down.
The call itself goes and fails in the remote terminal because it is
busy at the moment.  And this call looks very similar, if the calling
party abandoned on a ringing phone.  Right, so go ahead and try to
remember what I was trying to say, basically, this shows the service
activation itself, where we are using to set up a BFC application in
line with the server ending here.  You do the service activation's and
demand that he find out that the calling party is available and at
that point, you tear the BFC down and to set up your re-invite, so you
set up the attempt, the call re attempt using the invite.  This is the
big one, this is why I showed everyone this was going to figure out
how to get the URI back to the calling party during this phase.
Because you're not going to go back to the server.  To do the call of
attempt you have to make it back to the callee.  There are a few
different ways that this can be made to happen.  In the current
document, we say that this 200 in pointing to has the caller ID
contact -- -- if we do that, to the right place and supply is not
going to go to the right place.  After some thought, I have been able
to three potential ways of handling this.

 So one thing that was proposed on the list is that we would convey
 the URI and BFCP in itself----it is currently, it is not really a
 good semantic match for what BFCP does.  Another suggestion would be
 to add a header field that specifically conveys the URI that you're
 going to use to contact the person.  We have decided quite a while
 ago and some London meeting, this was not exactly how you wanted to
 make this happen.  You can recall that Dave was talking about -- --
 how many wasn't going to have, every service listed to -- I service
 and URI.  We decided it probably isn't the way to go

NEW SPEAKER: I'm not sure why it is a good matchup with BFCP, if you
think about it.  It is just trying to provide access to a resource.
One might imagine that when you win the resource via the four control,
you get past the reference to the resource that you have one.  While I
got that works?

NEW SPEAKER:  it very well may be my sense of aesthetics.

NEW SPEAKER:  that is the one I thought

NEW SPEAKER: okay, I like to use BF CP, and the third one I was going
to suggest and it is probably what I like, it is doing it and refer.
-- -- witnesses torn down, I send a refer back to the calling party.
And you would essentially have the URI by it self in sip terms,
meaning I want you to go ahead and call the person that.  I don't like
that I'm taking from the expression on your face?  All right.

NEW SPEAKER: you have touched upon my allergic reaction to refer with
an implicit semantics problem.  This is a refer that means, this is
your return call for the call or whatever activation you have before
you have no one.  So you have to correlate it altogether -- -- and
that's your toggling a URI for four control -- --

NEW SPEAKER: if you look at, this is semantically identical to a blind
call transfer

NEW SPEAKER: but it is not blind.  It is highly contextual.  In the
context of the BFC surface that has been activated.  Again, this is my
beef with refer; that refer always has a surround context of that is
supposedly there to help you interpret it and I sometimes it goes

NEW SPEAKER: so using refer for a call transfer -- -- it makes it
sound like you said deprecate refer, never use it for anything,
because this is one of the canonical reasons that we made refer exist
in the first place.

NEW SPEAKER: I'm not saying that, but in the BFCP, -- -- for other
services that I wanted a for control, you get whatever you are I
couldn't represent anything.  It seems pretty generic.

NEW SPEAKER: I was suggested that in the foreground we add a new TSC
-- -- TLV that was basically.  Here is the URI -- -- okay

NEW SPEAKER: hi, I don't object to what Jonathan suggested, I think
this is a perfectly reasonable place to do a refer.  I will select to
read something from ---- the reply to header field contains a logical
return URI that may be different from the header field.  For example,
you are a URI, I may be used to return calls -- --

NEW SPEAKER:  I like that.

NEW SPEAKER: I wrote and entered the draft trying to maneuver I uses
-- -- now I was looking at your refer, is that referred inside the
CCBS dialogue that is established at the top?  In the context, the
referrer means that the user's interaction with his user agent is to
be continued in the same way as it was before, but the dialogue is to
go somewhere else.  That would therefore mean that in the CCBS the
situation.  He is listening to the handset.  And I don't believe that
is the way CCBS works

NEW SPEAKER:  I missed to the antecedent for the

NEW SPEAKER:  no pronoun

NEW SPEAKER: the color user agent on the left-hand has a user
attending to it, because the call re attempt at the bottom is an
established a phone call with a person.

NEW SPEAKER:  I'm sorry, I'm not understanding

NEW SPEAKER: I'm trying to understand what that referred to as, refer
inside a dialogue means that the user on one end continues interaction
with the user agent.  But the dialogue that he is talking
interchanges.

NEW SPEAKER: that is effectively what it is, but that is a very long
time when the user is not going to be particularly interested in the
device.  He's going to press a button and walk away.  And hour later
when a person becomes available.  It will ring at him

NEW SPEAKER: refer inside existing dialog does not ring when the user
agent is received -- --

NEW SPEAKER: it is yet another semantic for reefer.  It is not an
instance of the re-

NEW SPEAKER: I can't disagree with you -- -- let me go ahead and run
Roland’s idea past Jonathan because I didn't get a read on him

NEW SPEAKER: so in what message is the reply

NEW SPEAKER: basically, the first place that we put the 205 to 200 or
the invite.

NEW SPEAKER:  wouldn't it have to be in the previous invite, the one that failed

NEW SPEAKER:  I'm sorry,

NEW SPEAKER: wouldn't it have to be any response to the original
invite, because that is the one you're trying

NEW SPEAKER: go back to slide.  -- -- 1 more slide.  This 183 is
telling you where it is setting the SCP session, so that 183 by what
we are talking about here, would have a reply to it that would
indicate where the, where this invite is.  This 200 indicates where
this invite goes.  I believe is what Roland was suggesting.

NEW SPEAKER: it would need to be in the 486, because basically this is
what you are replying to

NEW SPEAKER:  the 46 isn't making it back to the user agent -- --

>> the thing I don't like is that this invite goes to the server, then
    you are being replied to, but you are not really replying to the
    same dialogue.

>>  If you put it there

NEW SPEAKER: if you put reply to share, I am saying that it makes more
sense to put it in the one that feels because that is the one you are
trying

NEW SPEAKER: you need to convey a URI back to the user agent, the
color user agent.  Or this invite goes and where this invite goes.  So
you're not going to be able to do that with just one thing.  You can
do that with a reply to in the 183 and a reply to a 200 with this
invite.  You have an objection to that?

NEW SPEAKER: can you move forward to the next slide.  The next one
after that.  There we go.  Actually, looking at it, what that refer in
the middle there, what you are really looking for is the out of
dialogue refer.

NEW SPEAKER:  okay

NEW SPEAKER: because then you are using the semantics you have defined
for it, because it is telling the user agent.  You must initiate the
call to the third party.

NEW SPEAKER: apparently that is what I meant.  I believe that Jonathan
is probably still unhappy with that

NEW SPEAKER: it is probably worth a step back, we are in the sipping,
we are in the micro sip level, I think there are probably bigger
questions around.  This probably the most little bit.

NEW SPEAKER: I actually put the open issues up in random order.  We
might just decide we brought this to our attention and we finish it on
our list.

>> This service is particularly interesting in that there is a feature
    requirement to trade off, but is actually very wide.  When you end
    queuing, you bring in a mass, when you start to add multiple
    endpoints on each side, and forking

NEW SPEAKER: he is reading, issue three for me.  How many are you
going to add to this?  How hard or going to make it?  We can make it
impossible.

NEW SPEAKER: that is why I think the problem is interesting in and of
itself to understand what the space is, where is the point where it is
not worth it?  If it is not hard to support this thing, then throw it
in, or is it much harder for this feature.  I think it is an
interesting question to explore for this one in particular.  It could
be the hardest feature that we have yet to a dress in it because it is
largely -- -- so

>>  we really do need to decide which one of these are important

NEW SPEAKER: what I'm saying is that it is an activity in and of
itself not to just say these are the requirements.  Let's go solve it,
but to actually look at for these different types of requirements here
is how much work complexity we would have to add to it so that rather
than doing the requirements and the mechanism.  You do them jointly to
figure out what's of requirements presents a reasonable size solution
with a reasonable functionality.

>>  I think we have a good thumbnail of the ones that came -- --

NEW SPEAKER:  I think we can copy the service definition -- --

NEW SPEAKER:  while difficult, it is realistic from their perspective

NEW SPEAKER: the existing definition -- -- that is why I got wrapped
around presence.  Yes, they don't do presents, because the stupid
phone.  We can actually do better in sip by doing this properly, not
anchoring ourselves to the PSP service definition.  There

>> the draft, it doesn't actually talk about -- -- makes a decision to
    tell the caller when this, it is conceivable to use the agent to
    turn around and discover to the residence and determined based on
    that when the optimal time is to tell the person they are able to
    call you.

NEW SPEAKER: that is why it is an example of, if we threw in a
requirement to support more than just dialogue, we find there is no
room of complexity for that feature.  Of course we know with queuing
it is massive

NEW SPEAKER:  we have seven minutes left for the presentation.

NEW SPEAKER:  right, this actually touches, it is not exactly -- --

NEW SPEAKER: maybe, it is very well to try to solve the open issues,
but I would like to get consensus on the overall approach as Adam
said.  It is okay?  Because we could -- -- I would like to

NEW SPEAKER: these are really details -- -- this is how it works, to
see if anybody wanted to talk about it

NEW SPEAKER: Adam says, all the things that people have been getting
more positive, some people disagreed in a high level.

NEW SPEAKER: the arguments have been down at this level so far, with
one major exception

NEW SPEAKER: yes, let's set aside arguments about whether they use
presents to achieve this or not, but I think the motivation tries one
to bring this to us was to have a service that could enter work within
the existence PSTN surfaces.  And I'm not sure that this is going in
the right direction.  I understood that there were certain issues
about the semantics of subscribe notify in the earlier proposal -- --
but I'm not sure that this is no king, this isn't making things worse.
If you consider the complexity of implementing this at the gateway.
Suddenly you have got to involve media streams, you have got to open
up holes through NAT files and things to support this which you didn't
have to do with the other proposal.  And indeed, I probably got some
communication between the two halves which you didn't have in the
previous 1 -- -- I'm not sure this is the most efficient way of
achieving that requirement, and also I think there might be some
issues with what happens with the final call comes in through a
different gateway from where you have got your queue.  I do not sure
that we have answered these fundamental questions yet, whether it is
really addressing the individual problem

>>   (inaudible)

>> I did mean issue for, but go to the first graphic, this is what you
    are talking about.  Just to help John's point, this is the issue
    we saw -- --

NEW SPEAKER: I would like to discuss actually the fact that we're
using BFCP to (inaudible), I don't think we really need to go down
this path, analyzing to detail, proposal, so you disagree with using
BFCP, let's hear what people have to say about so interested in the
details

NEW SPEAKER: I just got me to -- -- that was the same thing.  I didn't
understand why we need to pull another protocol into to use this and
why we couldn't use dialogue -- -- like I say here is the URI were
going to use BFCP and here is the one for dialogue is a free-for-all.

NEW SPEAKER: if that is what we wanted, no amount of specification
needs to be done,

>> (inaudible)  

NEW SPEAKER:  that is the problem -- -- people have a requirement,

>>  please use the microphone

>> okay, the one additional requirement that makes that very
    difficult.  Here is a requirement to be able to cause a position
    in the queue and resume your position in the queue.  And once you
    go down that path is the sort of thing you can do with the
    existing event package.

NEW SPEAKER: I agree with the previous two speakers, it seems to me
that we are jumping into something really complicated.  And we took
some requirements for granted.  I don't believe, we want to this that
bad to get into -- -- in my mind the idea of doing binary for -- -- is
insane.  I think it is overkill, and I don't think we necessarily
really agreed on the requirements.  And if the people that supposedly
asked for the requirements and saw this, I do not think they would
implement it.  I will say that there are many different flavors of
this and regions of the world, and they were sufficiently worked
sufficiently differently that it is not clear to me that we are
necessarily doing the right thing.  So I have got a really big warning
sign here that I think we are doing something way too complicated for
our own good, and I would not implement this.  I would look at this
and I say, I would do something else to do feature equivalent to what
we need and to try to figure out a different way to deal with the
supposedly -- -- if the queuing is that important, figure out a way to
deal with that.  I don't think the requirement is to match necessarily
the current PSTN implementation.  It needs to be compatible, maybe,
but I think I agree with John, this is not going the right direction.

>>  These two speakers,

NEW SPEAKER: I think I like this -- -- you, the fundamental problem is
when you address using BFCP to control some resource like this -- I
think it is correct.  Obviously it is complicated, yes, but think for
a second that from this point of view I can expect to that BFCP is
going to be implemented.  Together with ---- all the other product of
months, so I don't think this is a problem and you are going to have
also BFCP in any system that helps to control conference -- -- or push
to talk, they already have their own conventional -- -- so I think
there is a complication there.  There might be a complication in
gateways, but I don't think there are any alternative situations that
make some problem easier.  We studied some dialog package and it
doesn't solve anything -- -- because that you manage to problems -- --
I would say that at least continue studying the problem

>> try to explain the requirements, because one of the people that
    brought it up, one the queuing, it is not something about the PSTN
    protocol, ---- is the user experience, so about the service, so
    cute management is not about not wanting to have the same queue
    management.  As we have anti-cat, so.  So the service as defined
    as specifications and at the service that is used to associate the
    cute management is part of the service, so I don't understand the
    argument that they are different flavors of something that is the
    service.

NEW SPEAKER: there is more to life than the ITU version of ---- and in
North America.  For example the use of something completely different,
and I don't think we have agreed that what we are trying to do here in
sipping is to replicate a feature that has been done by another
standards body.  And I think this is a slippery slope.  We start doing
that we are going to get a gazillion other features -- -- and I don't
think it is the right thing

NEW SPEAKER: this will also be asked on the main list, but at least we
get a feeling in the room of which one actually, who thinks actually
using BFCP to solve a problem or implement the service is the right
way to go, and I will be asking who doesn't think so.  Please raise
your hands all of you who think

>> I just, I was thinking that, given that it was something we were
    talking about requirements, it was almost as if you're going to
    ask that we wanted to accept that level of requirements,

NEW SPEAKER: I would like to get a feeling -- -- we can discuss the
requirements and we will as I said to discuss this further on the main
list, but I would like to get a feeling for the room.  That would be
useful in my opinion

NEW SPEAKER: we just need to be careful about what sipping is going to
do, what organizations take that as far as I understand the sipping.
It is going to provide the mechanisms that might support this but you
wouldn't actually define the service.  Basically, a you have a set of
requirements -- -- or the object of sipping might be an extension PFCP
if we are going away

NEW SPEAKER: I fully understand that, not saying we are going to do
anything.  We are not supposed to.  Trying to get a feeling in the
room of who thinks BFCP is good and who doesn't think so, this is not
a binding decision I will actually ask the same thing in the main list

NEW SPEAKER: we are not defining the service here, we are defining the
tools that build the services and I'm trying to point out the
interesting things you can do -- you can do this using presence or
dialogue and package, you can maintain the end of cues or at the end
of a network, it would define as protocols.  You can define the
service in any number of ways.  So I think we are going on a way to
not define the service -- --

NEW SPEAKER:  your draft only has that

NEW SPEAKER: the draft talks about several permutations on this,
client-based and a server-based implementations of the cues.

NEW SPEAKER: we are running out of time, so please all of you who
think it would be okay to use BFCP.  Please raise your hands -- you
shall I repeat?

>>  I think we are really premature

>> I hope you asked how many people they don't feel like they know
    enough to answer the question.  There

NEW SPEAKER: maybe we are premature to try to answer this question, so
we will try to go on to.  I see requirements and take this discussion
to the main list.  Thank you.

NEW SPEAKER:  next up is -- -- Paul

NEW SPEAKER: okay, I'm here to do offer/ answer usage, I'm not the
primary author, but I will talk about it, it is good.  This has a
folklore. Mostly, there has been discussion on this subject forever on
the list and people are constantly confused.  This is an attempt to
write down what some people have in their heads.  And, at the moment
the intent is that this is not a normative document.  But it is
clarification of operand through usage, offer/ answer.  I'm not sure
that it is appropriate, as some kind of informational thing, if
anybody can tell me what is most appropriate I would be pleased.  It
consolidates stuff from a lot of sources.  There are a bunch of RFC
that have stuff related to offer answer and a bunch of folklore that
came up.  There was a very long debate, I don't know if it was a
diplomat who said the something -- -- a couple years now.  At least
ago, and, a lot of the stuff that we talk about now came out of that
discussion.  And it was disappearing.  Like I said, I think there is
going to be a need for some normative clarifications at some point.
This work will recommend those courts seems like they are necessary.
But I don't see that this is a normative document itself.  It is
already serving its intended purpose, these questions about offer,
answer, all the time and certainly I have been sending people to this
document for a while.  It is not in final form and yet