[04:00:19] --- ttfr has joined
[04:00:32] --- ttfr has left
[04:53:24] --- bman has joined
[04:53:33] --- bman has left
[05:32:59] --- kkyzivat has joined
[06:09:25] --- kkyzivat has left
[08:03:53] --- xmlscott has joined
[09:57:41] --- xmlscott has left
[13:58:18] --- spencerdawkins has joined
[13:58:46] <spencerdawkins> ---------------------- now service-ID ad hoc meeting
[13:59:11] <spencerdawkins> want to figure out if we can do something that satisfies everyone
[13:59:24] <spencerdawkins> concerned about 3GPP requirements and timeframe
[14:00:23] <spencerdawkins> it would be great to have a document that explains service identification
[14:00:54] <spencerdawkins> people are trying to use for authorization, accounting, etc. want to seperate all this
[14:01:29] <spencerdawkins> document would go through some use cases - have already done this in Jonathan's WG
[14:02:20] <spencerdawkins> problem starts when client has to put a header in, that doesn't really say what to do
[14:03:41] <spencerdawkins> billing-info header?
[14:03:53] <spencerdawkins> billing based on the service
[14:04:11] <spencerdawkins> henning - tried to make this orthogonal - from a trusted node
[14:04:43] <spencerdawkins> might be ingress charging differential, want to pull out pieces
[14:05:32] <spencerdawkins> would people like this document, even if it's not for 3GPP?
[14:06:06] <spencerdawkins> cullen likes this - timing problem?
[14:06:53] <spencerdawkins> 3GPP wants service-ID for lots of reasons - capture them all? We think "yes"
[14:07:38] <spencerdawkins> elephant - people want to insert intermediate nodes
[14:08:54] <spencerdawkins> do we agree on jonathan's "do what I say" model?
[14:09:38] <spencerdawkins> header would be built on signaling contents, only in trusted domains, stripped at borders
[14:10:03] <spencerdawkins> talking about what we do in this room, or what we do in the working group?
[14:10:18] <spencerdawkins> going for stepwise consensus
[14:10:41] <spencerdawkins> problem has been there for a long time, people try lots of things to solve it, write that down
[14:11:07] <spencerdawkins> migrate current practices to something we bless - need to analyse solutions
[14:11:47] <spencerdawkins> point isn't "use a different header than accept-contact"
[14:12:28] <spencerdawkins> do we have to convince people to make a change to our recommendation?
[14:12:50] <spencerdawkins> some people are doing the right thing - don't try to stop that
[14:13:09] <spencerdawkins> there are things that are broken, that people are fixing in broken ways
[14:13:29] <spencerdawkins> not talking about solution, don't have agreement that people are breaking things
[14:13:53] <spencerdawkins> what does "do what I say" really mean?
[14:14:07] <spencerdawkins> SIP message is sufficient to figure out what to do
[14:14:53] <spencerdawkins> network knows what to do, based on INVITE, SDP. What else does network need to know, that we can't tell it yet?
[14:15:35] <spencerdawkins> saying magic words doesn't tell you what to do FROM THE SIGNALING
[14:16:19] --- cullenfluffyjennings@gmail.com has joined
[14:16:57] <spencerdawkins> multimedia vs telephony wasn't the right example, because you can tell by SDP parameters being different
[14:17:40] <spencerdawkins> video streaming vs video conferences - destination resource is known and different
[14:18:19] <spencerdawkins> eric - if we differentiate billing based on client-inserted header, the clients will be requesting the cheapest service a week later
[14:18:35] <spencerdawkins> andrew - agree with "do what I say"
[14:19:24] <spencerdawkins> POC has unique SDP - another bad example. filtering SDP to figure stuff out is complex and has a performance hit
[14:20:02] <spencerdawkins> still need to simplify problem - won't have all the SDP in billing
[14:20:14] <spencerdawkins> must simplify and summarize
[14:20:32] <spencerdawkins> another part of the problem - also have to dispatch to right contact
[14:20:55] <spencerdawkins> contact may not support a service - SDP isn't enough
[14:21:19] <spencerdawkins> callerpref can't express QoS parameters
[14:22:12] <spencerdawkins> jonathan - value is different content - target URI is different, identifies the value - have to use that, or there's a DOS attack
[14:22:46] <spencerdawkins> you don't run into problems when you "do what I say"
[14:23:38] <spencerdawkins> if you use SIP for IPTV, send INVITE to heros_episode34@verizon.com. Service is that I'm connecting to cool URI
[14:24:07] <spencerdawkins> if the service is different because you're connecting to a service provider service, service provider already knows
[14:24:58] <spencerdawkins> isn't unusual that protocols convey information that is only meaningful at a higher layer - ethernet, IP protocol field. Would not be unusual to do this in SIP
[14:25:24] <spencerdawkins> information could be used to dispatch to the proper target
[14:25:44] <spencerdawkins> 3GPP question - how do we do what we want to do without violating SIP?
[14:25:58] <spencerdawkins> some services are no different than well-known ports
[14:26:21] <spencerdawkins> would like to deliver SIP INVITE to right target
[14:26:40] <spencerdawkins> we already have MIME type carried in body of messages
[14:27:54] <spencerdawkins> eric - andrew knows about this - unquestionable that deriving service from SIP message is computationally expensive - must be able to figure it out, but then cache it
[14:28:11] <spencerdawkins> can't trust handset, can't trust other networks - have to figure it out for yourself
[14:29:20] <spencerdawkins> if you're going to do what you mean, don't send anything BUT service-ID, it's not SIP, but we don't care
[14:29:50] <spencerdawkins> analogy with Ethernet not helpful - this is routing at the SIP level, modifying messages themselves
[14:30:14] <spencerdawkins> "what about routing" - if we need tags, we identify the things we need
[14:30:41] <spencerdawkins> if the same AOR can support two services, we have to do something, but that seems unreasonable
[14:31:18] <spencerdawkins> "Do 151, and look that up in an RFC" - no value
[14:31:55] <spencerdawkins> rohan - went through jonathan's list - think we can do everything on his list
[14:32:17] <spencerdawkins> IM vs Software upgrade - use content-distribution and/or request-URI
[14:33:03] <spencerdawkins> can't trust charging from the terminal, but can't reject anything that hasn't got service-ID - breaks interoperation, don't go there
[14:34:03] <spencerdawkins> assume that we can differentiate - make sure we don't enter same service with different content - "only different types of services"
[14:34:09] --- cullenfluffyjennings@gmail.com has left
[14:34:40] <spencerdawkins> eric - not a targeting issue, you're fetching content but that's outside of SIP
[14:36:29] <spencerdawkins> dean - not clear that there are expectations for service-ID that aren't realistic - don't know anything about SDP, etc. differences but there's a billing rate differences - this only works if you have control of the network and can trust everything to honor the service class
[14:37:10] <spencerdawkins> jonathan - SIP doesn't have port numbers, it's like letting vendors decide what the port numbers are - good luck getting anything to work
[14:38:28] <spencerdawkins> cullen - reminds me of e-mail thread on list - don't know anything I didn't know from that. any ideas that would move us forward?
[14:39:49] <spencerdawkins> spencer - do we all agree with "do what I say"? We don't know that now
[14:39:59] <spencerdawkins> we should put updated draft out for comments
[14:40:15] <spencerdawkins> 3GPP is already part of release 7, frozen
[14:40:30] <spencerdawkins> lot of pressure to get this done, need some solution quickly
[14:41:20] <spencerdawkins> EKR - bored by back-and-forth - is 3GPP still going to find this objectionable?
[14:42:00] <spencerdawkins> two proposals - service-ID, or add the components that are missing
[14:42:13] <spencerdawkins> jonathan - humm on the draft I proposed
[14:42:30] <spencerdawkins> want to do a liaison statement, too
[14:42:49] <spencerdawkins> do we have a combination of headers we know we can look at?
[14:43:17] <spencerdawkins> rohan can come up with a list, who can look at this and say that it will work? or has 3GPP mind already been made up
[14:43:37] <spencerdawkins> not just SDP, it's analysis of whole message
[14:45:01] <spencerdawkins> jonathan - take a humm to have SIPPING adopt a draft on "do what I say", perils of inserting a header, why it's important to "do what I say".
[14:45:32] <spencerdawkins> may define a P-header, but that's optional -
[14:45:56] <spencerdawkins> does humm mean you agree on "do what I say" definition?
[14:46:04] <spencerdawkins> yes - this is the fundamental debate
[14:46:22] <spencerdawkins> jon - no objections to doing this humm
[14:47:07] <spencerdawkins> in support of jonathan proposal?17 - opposed? 7 abstains? some
[14:47:56] <spencerdawkins> we are agreeing to consider 3GPP ("real") requirements
[14:48:49] <spencerdawkins> dean - some people really want to meet a requirement that can't be met - need to know this
[14:49:04] <spencerdawkins> "can't be met in an Internet"
[14:49:14] <spencerdawkins> no one has enumerated the requirements
[14:49:53] <spencerdawkins> 23.228 actually has "put this header in at client" requirements - this isn't the real requirements
[14:51:06] <spencerdawkins> very good requirements, additional requirements are optional, let service providers do that they want and have handsets run transparently
[14:51:53] <spencerdawkins> must be computationally feasible - "evil bit" may still be the mechanism, will be proprietary if we don't define it in IETF
[14:52:29] <spencerdawkins> looking for mechanism for charging in a simple way - don't read the message to figure this out
[14:53:01] <spencerdawkins> EKR - if the choices are "define the evil bit" or "we'll do it proprietary" - there's nothing to talk about.
[14:53:18] <spencerdawkins> ----------------- adjourning to the social... ------------------------------
[14:54:57] --- spencerdawkins has left
[17:48:56] --- spencerdawkins has joined
[18:04:07] --- spencerdawkins has left
[20:09:24] --- sakuma.macx has joined
[20:29:21] --- sakuma.macx has left