[04:25:14] --- william.tan has joined
[04:25:20] --- william.tan has left
[04:54:12] --- william.tan has joined
[04:54:15] --- william.tan has left
[08:35:16] --- william.tan has joined
[08:55:23] --- ttfr has joined
[09:02:26] --- Nacho.Mas has joined
[09:02:33] --- Nacho.Mas has left
[09:02:36] --- csirkin has joined
[09:03:52] --- ysuzuki has joined
[09:04:04] --- ysuzuki has left
[09:05:04] --- ysuzuki has joined
[09:08:30] --- danyork has joined
[09:08:50] * danyork has set the topic to: SIPPING Mtg 2: Thursday, July 12
[09:09:12] <csirkin> have the presentations been posted?
[09:09:26] <csirkin> I don't see them on the agenda page
[09:11:40] --- Nacho.Mas has joined
[09:11:45] --- Nacho.Mas has left
[09:12:13] <danyork> csirkin: For whatever reason, they are over at softarmor.com - http://www.softarmor.com/sipping/meets/ietf66/index.html
[09:12:24] --- Shida has joined
[09:12:28] --- Shida has left: Disconnected.
[09:12:28] <danyork> slides are here - http://www.softarmor.com/sipping/meets/ietf66/slides/index.html
[09:12:41] * danyork has set the topic to: SIPPING Mtg 2: Thursday, July 12 - slides at http://www.softarmor.com/sipping/meets/ietf66/slides/index.html
[09:13:01] <danyork> currently in Salvatore Loreto's IMS presentation
[09:13:05] <csirkin> danyork, thanks
[09:14:05] --- Shida has joined
[09:14:08] --- isudo has joined
[09:14:58] --- Glenn Parsons has joined
[09:17:58] <danyork> presentation is over and five people at the mic now
[09:19:26] --- Tony has joined
[09:20:05] --- richard.barnes has joined
[09:20:13] --- miki has joined
[09:22:13] --- muonzoo has joined
[09:22:33] <muonzoo> what were the RFCs Eric quoted?
[09:22:40] <danyork> Bob (?) at the mic trying to understand what exactly is being asked about
[09:22:49] <muonzoo> Paul K at mic
[09:22:52] <danyork> muonzoo: missed it
[09:22:58] <muonzoo> anyone?
[09:22:59] <danyork> muonzoo: thanks for the correction
[09:23:23] --- ttfr has left: Replaced by new connection
[09:24:06] <danyork> Martin Daly at mic - it would be helpful if this was described in more detail
[09:24:54] <danyork> martin - I am assuming these solutions will be for more than just wireless, correct?
[09:25:03] <danyork> salvatore - yes
[09:25:30] <danyork> eric - standards need to be set here, so that IMS <-> non-IMS integration will work well
[09:26:26] <danyork> eric at mic - requests for services and requests for devices need decoupling
[09:26:40] --- xmlscott has joined
[09:27:03] <danyork> -- question for the Jabber chat room - are there people here who are NOT in the physical room here in Montreal who *want* scribing?
[09:27:26] * muonzoo has set the topic to: SIPPING Mtg : Slides at http://ln-s.net/BlG
[09:27:29] <william.tan> remote here
[09:27:29] <danyork> i.e. do I need to scribe or is everyone here in the room listening?
[09:27:36] <william.tan> from GMT+10
[09:27:38] <danyork> okay
[09:27:46] <xmlscott> has anyone clarified whether these service identifiers specify a: service type or a service instance ?
[09:27:49] <danyork> I'll keep going than
[09:27:52] <william.tan> thanks :)
[09:28:05] <muonzoo> Mikko (?) at mic.
[09:28:19] <muonzoo> scott : not that I know or have heard
[09:28:40] <william.tan> but i'm tuning in as well so the "name" at mic scribes are sufficient for me
[09:28:49] <danyork> xmlscott: are you here? do you need that question asked?
[09:28:55] <muonzoo> scott's in the room
[09:29:02] <danyork> muonzoo: thanks
[09:29:08] <danyork> jonathan rosenberg at mic
[09:29:29] <muonzoo> s/Mikko/Marcus/g (oops)
[09:30:26] <muonzoo> Dave Oran : that would be much better (laughter)
[09:30:26] --- Tony has left
[09:30:54] <danyork> JR - the problem you are running into is the issue of many apps on what device with multiple URIs
[09:31:10] <danyork> someone calling might only have 1 phone number or URI... yet phone has many apps
[09:31:25] <danyork> JR- presence messages help with this
[09:32:55] <danyork> JR - it's better when URIs are *learned* versus *constructed
[09:34:03] <danyork> chair asking a question
[09:34:59] <danyork> Paul at mic - need better examples in the draft
[09:36:05] <danyork> markus at mic - presence that JR mentions could work... but not sure it meets the requirements - what happens if URI can't be learned?
[09:36:26] <danyork> JR - well, if you don't know someone's phone number, you can't call them
[09:37:13] <danyork> JR and markus debating need for presence
[09:37:45] --- frodek has joined
[09:39:26] <danyork> andrew at mic - deploying a presence svr probably wouldn't go down well with 3GPP... and better examples are needed
[09:40:38] <danyork> roni at mic
[09:41:24] <csirkin> chaos at mic
[09:42:00] <danyork> rohan at mic - how many people listening to this actually *understand* the requirements?
[09:42:11] <danyork> only 4 or 5 hands raised
[09:42:55] <danyork> paul at mic
[09:43:29] --- cullenfluffyjennings@gmail.com has joined
[09:43:43] <danyork> JR back at mic
[09:44:48] <danyork> andrew back at mic
[09:47:05] <danyork> final commenter at the mic (don't know his name) - discussions shouldn't be limited to only URIs
[09:47:08] <danyork> new preso
[09:47:13] <danyork> Richard Ejzak from Lucent
[09:47:25] <danyork> http://www.softarmor.com/sipping/meets/ietf66/slides/Early%20Media%20Authorization.ppt
[09:49:04] <danyork> slide 2
[09:49:10] <danyork> slide 3
[09:49:54] <danyork> slide 4
[09:50:36] <danyork> slide 5 - local policy options
[09:50:47] --- ttfr has joined
[09:51:44] <danyork> slide 6
[09:52:19] <danyork> slide 7
[09:53:25] <danyork> slide 8
[09:53:33] --- Nacho.Mas has joined
[09:53:43] --- Glenn Parsons has left: Replaced by new connection
[09:53:44] --- Glenn Parsons has joined
[09:54:51] <danyork> slide 9
[09:54:57] --- Nacho.Mas has left
[09:55:23] <danyork> slide 10- RFC 3960 recommendations
[09:56:29] * danyork has not heard of SIP-I before
[09:56:50] --- fparent@jabber.org has joined
[09:56:53] --- sakuma.macx has joined
[09:56:57] <danyork> slide 11- draft-ejzak-sipping-p-em-auth-01
[09:57:28] * csirkin hasn't either
[09:59:50] <csirkin> slide 12
[10:00:49] <danyork> slide 13
[10:02:54] <csirkin> 14
[10:03:12] <csirkin> Jabber scribe load balancing
[10:03:32] --- mankin has joined
[10:04:24] --- sakuma.macx has left
[10:04:48] <danyork> :-)
[10:05:07] <danyork> final slide - and queue of 4 already at the mic
[10:05:19] <ttfr> _sip._udp.sipping.com. 43200 IN SRV 0 50 5060 csirkin _sip._udp.sipping.com. 43200 IN SRV 1 50 5060 danyork
[10:05:24] <danyork> csirkin: thanks, by the way, for the load balancing
[10:05:28] <ttfr> ;-)
[10:05:55] <csirkin> np
[10:06:19] --- richard.barnes has left
[10:06:47] <danyork> eric (?) at mic
[10:06:58] <danyork> going back to slide 14
[10:07:07] <danyork> Blocking at the private network border
[10:07:17] <csirkin> big line forming at the mic
[10:08:07] <danyork> franz at mic
[10:08:38] <danyork> franz - bad user agents will ignore headers - and CRBT is a poor example to use
[10:09:11] <danyork> speaker - some confusion here. intent is not to tell user agents how to behave. point is for communication between proxies
[10:09:23] <danyork> speaker - nothing to do with end users
[10:09:55] --- sakuma.macx has joined
[10:09:59] <danyork> franz - but people will look at this and say that they can use this header
[10:10:11] --- dumdidum has joined
[10:10:48] <danyork> franz - this has the aura of "you set this and things will be fine"
[10:13:14] <csirkin> hadriel kaplan speaking
[10:14:16] <danyork> hadriel - thinks this is a good and simple idea
[10:14:20] <danyork> adam roach at mic
[10:14:30] <danyork> well written, well-scoped draft
[10:14:45] <danyork> adam - much more elegant solution
[10:14:57] <danyork> paul at mic
[10:15:22] <danyork> paul - obviously messy area... "p-headers should do no harm"... is there harm here?
[10:16:19] <danyork> paul - either we shouldn't have early media at all - or should have reasonable expectation that it works
[10:17:32] <danyork> speaker - networks are going to deploy SBCs and block media when they think they need to
[10:17:56] <danyork> speaker - this header gives them a chance to know data
[10:18:08] <danyork> richard barnes from AT&T at mic
[10:18:25] <danyork> richard - what is the operational need for early media?
[10:18:39] <danyork> richard - why not treat early media as a race condition with SIP?
[10:18:59] <danyork> speaker - legacy... telephone networks do it today
[10:19:09] <danyork> dale worley at mic
[10:19:21] <csirkin> back to slide 13
[10:19:37] <danyork> dale - who rejected alternatives?
[10:19:45] <danyork> speaker - I did, based on TISPAN
[10:20:01] <danyork> dale - slide should have said "TISPAN rejected
[10:20:06] <danyork> dean willis at mic
[10:20:12] <csirkin> dean - early media is my fault
[10:20:43] <danyork> dean - we did it early on to work like the PSTN
[10:20:56] <danyork> dean - it is completely true that early media is compleetely broken
[10:21:32] <danyork> dean - we know enough to interop with the PSTN without using early media
[10:22:15] <danyork> dean - while this is a draft that works well within its constraints, it doesn't solve the fundamental real problem with SIP
[10:22:45] <danyork> speaker - yes, there's a problem... this header is for informational purposes within a *private* network
[10:22:56] <danyork> speaker - header not externally visible
[10:23:16] <danyork> dave oran at mic
[10:23:41] <danyork> much laughter
[10:23:58] <danyork> dave - how many hours have we spent discussing early media
[10:24:03] <muonzoo> proposes 2 new drafts / RFCs
[10:24:06] <muonzoo> 1) No early media
[10:24:11] <muonzoo> 2) No billing on 200s
[10:24:17] <muonzoo> (*applause*)
[10:24:27] <danyork> marin daly from AT&T at the mic
[10:24:31] <muonzoo> Martin Dolly: invokess the spectre of American Idol (AGAIN). Ugh.
[10:24:45] <muonzoo> FCC will mandate EM b/c there are other applications where EM is needed .
[10:24:51] <danyork> martin - could stand up here all day talking about early media
[10:24:51] <muonzoo> (*lots of woahs*)
[10:25:10] <muonzoo> Oran : argues that you are conflating something (EM and billing)
[10:25:14] <danyork> rohan at mic
[10:25:35] <muonzoo> Rohan Mahy : proposal that a g/w that recvs req for back channel ... sends 200 ok w/ a header that indicates billing inactive.
[10:26:13] <danyork> rohan - doesn't think this pheader does any harm
[10:26:18] <muonzoo> RM : thinks that having applications that intentionally use EM for 2-way comms is evil
[10:26:24] <danyork> rohan - we should try to get rid of EM
[10:26:27] <muonzoo> Fracois Audet
[10:26:30] <danyork> francois audet at mic
[10:26:33] <danyork> :-)
[10:26:43] * muonzoo drops to deal with something else
[10:26:51] <danyork> muonzoo: you can scribe
[10:26:56] * danyork laughs
[10:27:00] <csirkin> that was a drive by comment by Rohan
[10:27:15] <danyork> brian at mic
[10:27:17] * muonzoo recalls that Rohan is good at those, thankfully he has bad aim
[10:27:25] <danyork> :-)
[10:27:47] <danyork> brian - this gives a patina to the solution, but doesn't solve the underlying problem (seems to be common thread)
[10:28:02] --- cullenfluffyjennings@gmail.com has left
[10:31:26] <csirkin> upcoming hum poll on whether to proceed
[10:31:39] <csirkin> whoops, hand poll
[10:32:18] <csirkin> speaker is pointing out that the scope of the draft is p header only
[10:33:04] <csirkin> 30 or so are comfortable moving forward, half dozen or so are uncomfortable
[10:34:08] <danyork> new preso
[10:34:16] <danyork> SIP Overload by Jonathan Rosenberg
[10:34:24] <csirkin> no link on softarmor
[10:34:47] <danyork> csirkin: yes, he said he hadn't sent in his slides (at the beginning of the session)
[10:35:22] <csirkin> oh, I must have missed that
[10:35:33] --- richard.barnes has joined
[10:36:21] <richard.barnes> For the record, I'm from BBN, not AT&T
[10:36:48] <danyork> overload issue is basically that when proxies are overloaded, the resulting 503s generate a large amount of traffic
[10:37:04] <danyork> richard.barnes: thanks
[10:37:37] <richard.barnes> danyork: no problem
[10:37:48] <danyork> JR - point is to maintain network throughput when faced with overwhelming number of packets
[10:38:16] * danyork 's security hat basically calls this a big-time self-inflicted DoS
[10:38:50] <danyork> someone at mic commenting on the requirements
[10:39:42] <danyork> someone == "Steve Norris"
[10:40:43] <danyork> chair - this will be added to WG chart once previous charter changes have been changed.
[10:41:05] <danyork> this == "requirements document" from JR
[10:41:27] <danyork> JR is addressing solutions proposed and design questions
[10:43:51] --- spencerdawkins has joined
[10:44:13] <danyork> henning had commented
[10:44:18] <danyork> volker hilt commenting
[10:44:25] <csirkin> Henning reiterates that this mechanism doesn't fix binge/purge problem
[10:45:59] <csirkin> Hadriel Kaplan
[10:46:00] <danyork> hadrial kaplan at mic
[10:46:39] <danyork> actually, csirkin, I'll drop back and let you scribe for a bit... got an email I need to answer
[10:46:45] <csirkin> ok
[10:48:18] <csirkin> sorry, the questioner didn't give her name
[10:49:08] <csirkin> should tuning the response on the receive side be standard or local policy
[10:49:26] <csirkin> JR - we should at least provide guidance
[10:50:07] <csirkin> Martin - agree you need to well define the behavior and need to make send behavior configurable
[10:50:52] <csirkin> JR - must support unknown devices
[10:51:21] <csirkin> Allan ? - classic open control problem, must understand the complexity
[10:51:31] --- richard.barnes has left: Logged out
[10:52:30] <csirkin> JR - wants to get TSVWG input during development
[10:52:32] --- Shida has left
[10:53:17] --- mankin has left
[10:53:38] <csirkin> Steve Norris - relevant bullit item "Do we use separate protocol or part of SIP itself?"
[10:54:50] <csirkin> Henning - 1) worried when people say there needs to be lots of knobs to turn
[10:54:56] <muonzoo> what has too many knobs according to Henning?
[10:55:40] <csirkin> I missed it, sounded like RED to me, but I'm pretty unsure of that
[10:56:27] <csirkin> 2) need to focus on things that will operate loosely
[10:56:29] <muonzoo> could have been RAID - but that makes no sense to me , oh well
[10:56:39] <csirkin> yeah, neither does RED
[10:57:24] <csirkin> ? - 1) could you call this application multicast because traffic could fork
[10:57:47] <csirkin> 2) could you show your data to the people who would have to work on the algorithms
[10:58:05] <muonzoo> Allison Mankin @ mic (ongoing)
[10:58:27] <csirkin> thanks muonzoo
[10:58:29] * muonzoo wonders if anyone is still remote and listening in ...
[10:58:47] <csirkin> william.tan said he was remote
[10:59:25] <csirkin> not sure if he's still listening though
[11:00:19] <csirkin> JR - perhaps add section to doc with use cases for simulation and modeling
[11:00:36] <muonzoo> Volker Hilt @ mic
[11:00:41] <csirkin> Volker - the goal is to avoid congestion collapse
[11:00:52] <csirkin> and maybe add optimization later
[11:00:52] <muonzoo> JDR : let's add that
[11:01:00] <csirkin> Vijay ?
[11:01:01] <muonzoo> Vijay
[11:01:29] <csirkin> should resolve the 2 mechanisms to 1 for interoperability
[11:02:02] <csirkin> Steve Norris from BT - probably not Multicast, probably unicast, not sure about admission control
[11:02:23] <csirkin> BT has published simulation data that they could offer
[11:03:00] <csirkin> I still don't know this questioners name
[11:03:16] <muonzoo> Name? Unknown and just stood next to her -- oops
[11:03:38] <csirkin> must make sure that this doesn't make congestion worse, Volker's draft uses 100 header which could make more traffic
[11:04:11] <csirkin> muonzoo: I'm sitting right next to the mic line and I've been trying to read her name tag and haven't been able to
[11:04:17] <csirkin> Spencer Dawkins
[11:04:27] <muonzoo> /csirkin - ok oh well
[11:04:34] <csirkin> next presentation
[11:04:51] <csirkin> http://www.softarmor.com/sipping/meets/ietf66/slides/SIP%20Perf%20Metrics.ppt
[11:06:02] <csirkin> slide 3
[11:07:17] <csirkin> slide 5
[11:08:05] --- sakuma.macx has left
[11:08:25] <csirkin> 6
[11:09:26] --- enrico has joined
[11:09:58] <csirkin> 7
[11:10:54] --- enrico has left
[11:12:09] <csirkin> Henning at the mic
[11:13:14] --- mankin has joined
[11:13:19] <csirkin> we've done this before, different communities want different types of metrics
[11:14:22] <csirkin> btw, the unknown questioner earlier was Janet Gunn or Guinn
[11:15:24] <csirkin> speaker - this is not intended to take care of everybody's needs, partially came out of SPEERMINT need to discuss performance between peers
[11:15:24] --- Nacho.Mas has joined
[11:15:53] <csirkin> Henning - need to have a clear scoping
[11:15:58] --- Nacho.Mas has left
[11:16:05] <csirkin> Sohel Khan
[11:16:18] <csirkin> consistant terms are important and he likes it
[11:16:21] <csirkin> Tom Taylor
[11:16:50] <csirkin> reinforce Henning's point, it's essential to define the requirements for a task, then to define the metrics
[11:17:08] <csirkin> pick your tasks that you're ready to tackle
[11:17:39] <csirkin> speaker - I wanted to see if there was interest and I agree that we need to better specify
[11:18:12] <csirkin> Scott ? - good work, we're finding in BMWG that it becomes increasingly difficult to keep up with scoping for this
[11:18:46] <csirkin> chairs taking hand vote
[11:19:03] <csirkin> whoops, hum vote
[11:19:28] <csirkin> no hums against
[11:19:50] <csirkin> clear consent that it is interesting to proceed though we have no cycles
[11:19:55] <csirkin> next presentation
[11:20:06] --- sakuma.macx has joined
[11:20:13] <csirkin> http://www.softarmor.com/sipping/meets/ietf66/slides/sipping%20call%20completion%200711.ppt
[11:20:37] <csirkin> slide 3
[11:21:10] <csirkin> 4
[11:21:24] <csirkin> 5
[11:21:32] --- mankin has left
[11:22:36] <csirkin> 6
[11:24:06] <csirkin> 8
[11:24:37] <csirkin> 9
[11:27:17] <csirkin> chair speaking
[11:27:57] <csirkin> TISPAN uses Subscribe/Notify for this, does the WG think this is a valid usage
[11:28:08] <csirkin> I didn't catch the name of the questioner
[11:28:57] <danyork> Miguel Garcia (Nokia) at the mic now
[11:29:25] <csirkin> at some point they were going to use Subscribe/Notify to a server to manage queue which somebody said could be used for other applications and be generalized
[11:29:30] <csirkin> thanks danyork
[11:29:36] <csirkin> Keith ?
[11:29:45] <csirkin> this isn't a queue per se
[11:29:57] <danyork> np... FYI, I have to head out now
[11:30:04] <csirkin> allan johnson? - there's some interesting things you could do with this
[11:30:04] <ttfr> Keith Drague
[11:30:06] <danyork> Alan Johnston from Avaya, BTW
[11:30:41] <csirkin> robert - I don't think there's anything wrong with this
[11:30:52] <csirkin> thanks ttfr and danyork
[11:31:17] <csirkin> moving on to slide 10
[11:31:56] <csirkin> 11
[11:33:50] <csirkin> 12
[11:33:57] --- fparent@jabber.org has left: Logged out
[11:34:46] --- ttfr has left
[11:34:51] <csirkin> chair - what do you think about the longer times for presentations
[11:34:57] <csirkin> and with that we're out
[11:35:31] --- spencerdawkins has left
[11:35:39] --- sakuma.macx has left
[11:35:43] --- isudo has left
[11:35:48] --- ysuzuki has left
[11:35:49] --- xmlscott has left
[11:36:11] --- csirkin has left
[11:42:18] --- frodek has left
[11:45:08] --- muonzoo has left: Computer went to sleep
[11:48:46] --- Glenn Parsons has left
[11:51:29] --- danyork has left
[11:53:08] --- dumdidum has left
[12:06:16] --- miki has left
[12:57:34] --- spencerdawkins has joined
[12:57:57] --- danyork has joined
[12:58:02] --- danyork has left
[13:30:54] --- william.tan has left
[13:41:03] --- mankin has joined
[13:42:46] --- mankin has left
[16:13:14] --- spencerdawkins has left
[16:45:09] --- spencerdawkins has joined
[17:39:14] --- spencerdawkins has left