MaryB:
Called to order
JDR:
Would like to have a
document whose general topic is "Here is the
problem: service
identification". This is needed because different people want to use it
for a lot of different things. Needs to document the problems associated with
the the asked-for approach.
"You really need to
figure out what is missing from the signaling".
Spencer:
Proposal on list to add a
billing ID as a subset problem. Would that help?
HGS:
Summary: Trying to split the
problem in pieces -- service selected is different from relevant tariff, and
needs an identifier in a different class.
JDR:
MaryB:
Question: What would we
deliver?
JDR:
Proposes: Would people find
interest in a document, purely informational, that discusses service ID and its
perils.
MaryB: Polls room, finds
agreement.
PKyzivat:
Question: What pieces do we
want to address in draft?
JDR:
Answer: All of the pieces
presented in the slide.
Spencer:
Asks: Do we all agree that
"do what I say" not "do what I mean" is the directive? Are
we agreed to fix the signaling to met the real requirements?
EKR:
Question: Is that not the
opposite of what the proposed P-headers would do?
Spencer:
Ans: The way you'd decide
what to do is by fixing the signaling so that a server at the edge of a
colluding group could use that signaling to insert a header.
Rohan:
Direction: Would prefer to
start talking about general way to solve problem before talking about
P-headers. Want to defer P-header discussion until ready.
Discussion continued . . .
MiguelGarcia:
One of the problems this
group is trying to achieve is to migrate current practices to an IETF method. We
need to do an analysis of the current methods and how they work to be able to
make this argument.
EricB:
We believe that what we're
proposing is the right way to do things.
So we should not worry about
convincing them to change from something that is broken.
Christer:
We need to be able to
explain to people what the pieces mean.
JDR:
If the signaling is
sufficiently explicit we can use it to do authorization.
Spencer:
Only one other person in
sipping jabber room.
Hannu:
Example: Online streaming vs
video conference -- how to differentiate?
EricB:
If a user supplied parameter
is used to differentiate billing, then it will get hacked.
Andrew:
POC negotiates a whole
protocol with one keyword. Trying to filter that out of the SDP at multiple
nodes would be very expensive.
ACMahendran:
The requirement is to
differentiate between contacts. Can't do that in SDP.
JDR:
But the target URI is
different -- it identifies the resource being accessed.
Not a separate URI. If you
were to use SIP for IP/TV, you would send an INVITE to something like
sip:heroes-episode-34@verizon.com. The service I'm getting is that I'm
connecting to a URI that will send me streaming content. You can bill form
this.
Milo:
It would not be unusual from
a protocol perspective to have a field
representing higher-layer
information. The question is how to
syntactically specify this
in SIP.
Rohan:
We do have this. It is a
MIME type. It can be completely opaque to SIP.
Eric:
Deriving the service from
whatever is in the SIP message is
computationally expensive.
It is better to do this once, then "cache"
it across the network. It
has to be deduced from the signaling,
because any inserted token
will be compromised. All we're talking
about with a "service
ID" is a compression technique.
HGS:
Reasoning by analogy is
dangerous. We're talking about a lot of stuff
that isn't covered by the
examples given. Most of this is just a
parameter-by-value vs a
parameter-by-reference model.
Rohan:
Different sub-destinations
for a body should be settled by content-
disposition.
Hannu:
Agree you can't trust the
terminal and need to look at SDP. But some
services can't be
distinguished that way.
Avshalom:
(didn't catch)
Dean:
Some of the requirements
here are actually not achievable in a real
network unless there really
is a an admission/exit model that is
contractually obligated to
support a service identifier flag.
Milo:
something I did not catch.
Cullen:
Want ideas on how to get
beyond this conversation in the next 13
minutes.
Rohan:
Want agreement on
what-what-I-say or not
hannu:
if we don't have something
soon, don't bother
Milo:
Two approaches offered: The
3GPP, and the JDR approach.
(much stuff lost)
JDR;
Would like to take a him on
doing a "do what I say" draft along with
a "perils of just using
a header".
Christer:
Question: So we're voting on
"do what I say" as a direction?
Ans: Yes.
POLL: In favor of doing a
do-what_say draft? 17 to 7.
AC:
I don't care about 3GPP. I
just want a solution to the real
requirements.
Dean:
There are intended
requirements that cannot be met in an internet.
This needs to be explained.
JDR:
23.228 has a requirement for
"What header can I put my evil-bit in"?
This is not a real
requirement.
Hannu:
It should be possible to
indicate several services in an INVITE.
Fabio:
Result should be
computationally efficient. If that takes an evil-bit
that's ok.
HughS:
We're not talking about
access to transparent services. We're looking
about stuff that is defined
by a service provider.