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.