[19:21:16] kpfleming joins the room [19:28:52] hanserik.van.elburg joins the room [19:29:10] hanserik.van.elburg leaves the room [19:29:38] ietf.hanserik joins the room [19:50:09] Joao Placido joins the room [19:51:21] martin.thomson joins the room [19:52:39] martin.thomson has set the subject to: martini, IETF 77 [19:53:43] Bernarda joins the room [19:54:23] Archive of MARTINI Virtual Interims: http://aboba.drizzlehosting.com/MARTINI/ [19:54:45] Meeting materials for IETF 77 MARTINI meeting: https://datatracker.ietf.org/meeting/77/materials.html [19:55:22] If you want to speak to the meeting, you can call in on Skype: baboba9132 [19:55:26] Alan Johnston joins the room [19:55:41] Otherwise, go ahead and use the Jabber room. [19:59:19] Adam Uzelac joins the room [20:02:09] suzukisn joins the room [20:02:48] xmlscott joins the room [20:03:22] Cullen being presented (as outgoing RAI AD) = he's getting more coffee (he got some from ECRIT) [20:03:23] brian1lindsay joins the room [20:03:50] that's the last thing we need - to speed up Gonzalo [20:04:12] is anyone having success with the audio feed? [20:04:22] yes - it's fine for me [20:04:38] yes audio is fine in europe [20:05:26] Dale Worley joins the room [20:07:57] maybe someone can give some background on the milestones [20:08:42] slight delay in locating the slides [20:10:26] no background... [20:11:25] bernie joins the room [20:11:39] MARTINI Reqs doc combines individual requirements and mixing problems documents into a single doc.... [20:12:02] Issues fixed in draft-ietf-martini-reqs-02... John will talk about open issue.s [20:12:19] Recent issues on tracker (1).... [20:13:41] as a consequence on the discussion on #17 it was identified that DES4 needs work [20:15:49] agree with Keith [20:16:29] rough consensus != unanimity [20:20:34] victor.pascual.avila joins the room [20:21:00] gonzalo at mic [20:21:01] Jon Peterson: "Dragons" explanation about perils needs to be in the requrements document. [20:21:21] Gonzalo: Be explicit about E.164 numbers.... [20:21:51] John Elwell: Will explain why E.164 is tractable vs. other addresses which are harder. [20:22:24] Issue #15: add req for local numbers as AORs (related to #6 and #16) [20:22:51] do not understand those diffculties [20:23:03] there always has to be a phone context [20:24:08] Paul: Local numbers *may* fall out... but what about 411? [20:24:10] audio dropped [20:24:16] not for me [20:24:19] not for me [20:24:20] back [20:24:29] Paul: Are they pertinent to problems at hand? Are they subject to inbound requests? [20:24:37] LoST [20:24:52] John: Not talking about 911, 112... not AORs on the PBX... what people had in mind were PBX extensions. [20:25:03] think that is correct [20:25:21] John: Where SSP was handling two+ PBXes in the same enterprise, allowing routing between them. [20:25:39] Keith: We need to handle local numbering plans... could involve any centrex, other PBXes in the private network. [20:25:54] yes that needs to be supported [20:25:57] John: Wasn't what I heard from folks who made the request... didn't hear about dial strings? [20:26:16] Keith: No. 3456@enterprise.com -- that's not a dialstring (or a local number) [20:26:22] private number plans != dialstring [20:26:24] Adam: Needs routing back to SSP to get back to PBX..... [20:26:38] keith was talking about tel:4365;phone-context=example.com [20:27:01] it i snot only about pbx to pbx but also mobile centrex to pbx [20:27:08] Adam: Was assuming that PBXes routed to each other... not going to SSP... [20:27:29] John (speaking as individual): was imagining that SSP wouldn't be involved... would route internally, bypassing SSP. [20:27:51] Keith: Had mentioned Centrex (PBX functionality hosted on SSP). Want to be able to host [20:27:59] anybody taking the remarks from the hjabberroom??? [20:28:05] john: Hosting Centrex hasn't come into terms of reference. [20:28:22] Hadriel: Centrex is already in the SSP... so private numbering goes through SSP to the headquarters... want to make sure that works. [20:28:25] yes [20:28:40] Adam: If we assume this has to work... you've destroyed mobility... use cases previously discussed don't work. [20:28:49] ??? [20:29:27] Hadriel: there are local numbers routed by the SSP... if we had the requirement, we'd need to make sure we could support private numbering plans. [20:29:39] John: Are you supporting addition of that requirement? [20:29:46] prefix anything you'd like to see taken to the mic with "mic:" [20:29:55] ah [20:29:56] Hadriel: No... by next meeting, we'll discover it will work... but doesn't need to be in requirements document. [20:30:18] Spencer: Would ask that anybody who has opinions about what we need to do, please send it to the list. [20:30:22] Gonzalo joins the room [20:30:38] Hadriel now presenting.... [20:31:05] Current Problems (for 3GPP/ETSI too) [20:31:17] No explicit indicator [20:31:54] vijay.gurbani joins the room [20:32:30] Dale Worley leaves the room [20:32:48] vijay.gurbani leaves the room [20:33:00] Hadriel: Can you submit why indicator isn't sufficient for configuation to be avoided? For a big PBX, sure... but mom and pop pizza shop we want to avoid this... [20:33:06] Dale Worley joins the room [20:33:15] nice pants [20:33:23] Richard Shockey: we want option tag due to confusion.... SSPs don't know what this register meeting is.. they need to know what to do. [20:34:23] PBXes sometimes change the Contact-URI..... [20:34:39] Wildcarded PAU not legal.... [20:34:48] Hadriel: Request-URI problem (one of the biggest ones) [20:35:20] Example: from originator to SSP to PBX.... in some SDOs Request-URI is left alone... in others it is modified. But can't be left along, because the PBX is not the domain of the SSP. [20:35:51] PBX is not in ssp.com domain... not authoritative for it, doesn't belong to it... in a peering model it would have been retargeted... but not what is specified. [20:36:29] Hadriel: Bruno pointed out that it causes problems for some cases, but no others... but want to specify a profile and have it always works... need an indicator to say that you've followed that profile, so you know that the PBX has implemented this spec. [20:37:14] Hadriel: Different drafts (Shaken vs. GIN) describe what should be done... but both are explicit. [20:37:26] Other problems we're NOT tackling (leaving "policies" to profiles) [20:37:50] Undefined behavior of PAU mismatch... REGISTER response growth... [20:38:27] Hadriel: this is about policy, not on the wire... consensus is that we will not tackle them. [20:39:07] Adam Roach on GIN.... [20:39:40] Adam: Some rehashing of interim meetings... changes from -00 to -01. [20:40:08] Assumptions driving design: PBX can't be assumed to be assigned a static IP address. No DNS entry can be relied up to resolve to A/AAAA of the PBX. [20:40:31] Overview.... adds new parameter for Contact URI, to indicate that it represents several actual contacts. [20:41:04] By limiting to globally unique E.164, don't have to do fancy mapping.... we end up with a convention.... [20:41:46] Adam: For bulk register, the Registrar semantically expands this special Contact into one contact for each DID.... [20:42:13] Changes since -00: Added Proxy-Require (not a simplification). Simplified Contact and GRUII URI Formats. [20:43:11] Proxy-Require is usually the "kiss of death" for deployment... chance you'd have an extension in every proxy is very low. In these circumstances it's not so bad, because it's not cross domain, but rather within a tightly constrained domain of control. [20:43:26] Adam: So deployment is tractable. [20:43:44] Dean Willis: Is Proxy-Require or contact parameter necessary for SBCs to work? Is it both? [20:44:40] Adam: option tag is the first thing and contact head field is the second thing. [20:45:18] Adam: Added more detail on public GRUUs (not as straightforward as it seemed it would be). [20:45:30] Adam: Use public GRUUs to turn around and create private GRUUs. [20:45:45] Adam: Not really uses cases, so started calling them "Wumpuses". [20:46:02] Simpler Contact Syntax [20:46:11] REGISTER message now contains Contact URI with no user portion. [20:46:32] MARTINI Contact URI still contains "bnc" parameter to mark it as requiring special handling. [20:46:46] SSP inserts called extension into user portion of registered MARTINI contact... [20:46:50] Public GRUII Changes [20:47:11] Remmoved "*" from "gr" parameter; PBX instead uses new "sg" parameter to adds its own device identifying token. [20:50:10] Example 3 from the draft with updated syntax. [20:51:00] mic:any reason there is not a user=phone [20:51:02] Wumpus 9 (formerly Example 9) [20:51:27] Adam: There wasn't room on the slide... there is in the draft. [20:53:09] Open Issue: user=phone [20:53:34] Current draft doesn't reat "user=phone" as special. Simply says that parameters from a MARTINI Contact URI must be... [20:53:46] Several options: Keep as-is (let PBX choose) [20:53:53] Forbid "user=phone" on "bnc" URIs... [20:54:03] or Forbid "user=phone" altogether. [20:54:23] henning at mic [20:54:36] Henning: Is this driven by implementations out there... or providing useful information? [20:55:11] Henning: Is this pragmatic....option 1 creates another error condition. [20:55:25] Adam: PBX is talking to itself.... [20:55:42] Henning: If it doesn't serve a deep symantic purpose.. [20:55:52] Adam: It's "user=phone", of course it doesn't! [20:56:03] Henning: Opens up obscure error conditions... (vote for option 1) [20:56:32] Christer: Couple of issues: Is this related to E.164? Second, are you allowed to have "user=phone" without user part? [20:57:09] Adam: If we asked people in the room... you'd get as many answers as people... [20:58:06] John Elwell: Wanted to choose an option... wasn't clear at the time that option 1 let the PBX choose... 4th option is that PBX is required to put it there... seems more like policy vs. protocol. [20:58:38] Hadriel Kaplan: What happens when it is "user=something else"? Like "user=fax"? [20:59:08] Hadriel: Needs to target a fax server? Can they *not* do this? Sometimes it comes from an ATA that is dedicated to fax, so you know it's a fax.... [20:59:33] Adam: You're talking about the nature of the originator... this is about the terminating party..... [20:59:42] Adam: I get calls like that... [20:59:53] Hadriel: Do you answer them? Or do you speak tones into the phone? [21:00:14] Adam: You're conflating originating and terminating characteristics.... [21:01:22] Adam: We don't want to have open GIN up every time someone defines a new header field! [21:01:30] Tyler joins the room [21:01:43] Hadriel: Can we get some time to think about this? [21:02:03] Paul Kyzivat: Has "user=fax" been proposed yet? [21:02:07] Hadriel: Not yet. [21:02:17] Robert: Not the insanity for this group to chew on right now. [21:02:32] Robert: Could recap the problem that this is trying to solve. [21:02:51] Adam: If PBX wanted "user=phone" to come back, would have to include it in the BNC contact. [21:03:13] mic: if there is no user=phone on the INVITE then it is not an E.164 number... is it really an issue on the REGISTEr [21:03:40] ples [21:05:50] The semantics of "user=phone" are not as well defined as to say that the user portion is an E.164 number. [21:06:02] Above is from Adam, typed in directly. [21:06:16] Jon Peterson: Let's not forbid it. [21:06:33] Jon: Is this about a (misguided) sense of semantic purity? [21:06:53] Jon: #1 sounds great. If people don't want to do that, let us know. [21:07:07] Spencer: Humm on #1 vs. not. [21:07:32] Keith: I object! [21:08:00] :-) [21:08:42] Keith: In regards to the adoption... large number of SSPs have objected... you need a service provider at one end of this~ [21:09:24] Cullen: Just trying to give some advice to author before painting the shed some more. [21:09:47] Richard Shockey: There are SSPs who want to do this? They happen to be U.S. cable operators... there is a difference of opinion [21:10:00] Spencer: sense of the room for #1. [21:10:10] Open Issue: List of Phone Numbers? [21:10:23] Tyler leaves the room [21:10:56] General directions is that neither the register nor its response needs to contain list of DIDs.... [21:11:30] Omission of DIDs in REGISTER makes it difficult for intermediaries to know which AORs might be related to this registration. [21:11:49] Would be trivial to add new header field or contact parameter to indicate number rnages. [21:11:58] Tyler Parkin joins the room [21:12:04] Adam: Do we really want to paint ourselves into this corner? [21:12:40] David Schwartz: Is there harm in proposing a mechanism? Everything you've done until now is fine... you may provide additional info, but doesn't affect bnc.... [21:14:04] Spencer: We haven't seen people saying they have to have this [21:14:11] Adam: It's not in the draft, but I think it should be. [21:14:33] Spencer: No reason it needs to be part of GIN... if people care about it, they can write it up. [21:15:16] Spencer: You have to solve size of response problems.... and question is whether it is worth it. [21:15:20] Adam: Nods. [21:15:22] personally, i see that being able to specify subsets/ranges belongs in the later work that goes beyond GIN, which might not even use REGISTER at all [21:15:47] because the whole point of GIN was to minimize changes required at registrars, and subsets/ranges defeat that purpose [21:17:00] Hadriel Kaplan: I think we need to keep it out of here... in Outbound we threw too much stuff in... it took 5 years. [21:17:26] Hadriel: It's a policy decision... leave it up to 3GPP or SIPForum..... they have the tools. [21:18:12] Hadriel: We just don't need it right now. [21:18:20] +1 [21:18:34] Keith: There is Section 3 of the requirements document which talks about how important it is to solve this. [21:19:03] Keith: Think about what you want. Most people want a list of URIs that are currently registered, not those created as a result of the registration occuring. URIs can be deregistered. [21:19:15] Keith: If you want this, you want to make the reg event package work differently. [21:19:52] Jon Peterson: This seems like a lot of work.... it seems more in common with how REGISTER is supposed to work to provide it... we should put up warnings to say we're not doing this if we don't do it. It seems surprising to not provide this. [21:21:49] Adam: DIDs up, DIDs down.... not just the list of currently registered DIDs... that would be semantically consistent with the way things work today. [21:22:02] Spencer: Do we need to figure this out to do GIN... or to ship GIN. [21:22:21] Adam: Like the idea to do this in an adjunct.... could do this once GIN is out the door... could be retrofit on. [21:22:51] solution to expanded message sizes : indirection [21:22:53] Spencer: I'm excited about anything that doesn't require us to "stop and talk for a while" about difficult problems we haven't been able to solve in the past (like message sizes) [21:23:29] John Elwell: I like the way forward..... as a separate draft... if you need to do this.... use reg-event package... if you MUST use register, put it in the Request. [21:23:56] Hadriel: Response DOES indicate what was registered. [21:25:03] Christer: Let's assume I'm registering that template... can I add or remove numbers? [21:25:20] Christer: What comes in the response? Do I get a template or a specific number? [21:25:29] Adam: They would ALL be listed.... [21:28:05] mic: so how do we get the information anbout the actually implicitly registered URI's to an edge proxy for the purpose of setting PAI [21:28:13] Other Pending items: #7 and #8: idnits and editorial. [21:28:28] #9: complete registration for new IANA registerered protocol items. [21:28:34] @hanserik: reginfo extensions? [21:28:37] #10: Analyze GIN vs. requirements. [21:29:02] @martin it seemes they dropped tha tin favor of the templet [21:29:40] @haserik: only in the context of the register, I think [21:29:57] @martin that is also what i mengt [21:30:33] Description of issues #11-14. [21:31:43] brian1lindsay leaves the room [21:33:54] as0-d91k joins the room [21:36:04] Question: How much can we get done by Friday? [21:36:14] Can we address #10 (requirements)? [21:36:20] John Elwell: I volunteer. [21:36:46] Adam: One reason issues aren't closed... is because I don't want to shine the car if it will never run.... [21:38:49] Adam: SSP does need to support Path for PBX to get what it wants. [21:42:13] suzukisn leaves the room [21:42:22] Joao Placido leaves the room [21:42:23] xmlscott leaves the room [21:42:31] kpfleming leaves the room [21:42:33] With the buffering of the audio stream, Bernard's text became real-time sub-titles as I heard people talking... [21:42:50] martin.thomson leaves the room [21:42:57] Alan Johnston leaves the room [21:45:18] brian1lindsay joins the room [21:45:21] as0-d91k leaves the room [21:47:51] ietf.hanserik leaves the room [21:50:43] Gonzalo leaves the room [21:55:18] Meeting adjourned. Will meet on Friday. [21:55:22] Bernarda leaves the room [21:56:11] Tyler Parkin leaves the room [21:56:16] Dale Worley leaves the room [22:01:34] mcharlesr joins the room [22:06:14] victor.pascual.avila leaves the room [22:08:49] bernie leaves the room [22:12:50] Dan Burnett joins the room [22:13:26] Dan Burnett leaves the room [22:19:28] Adam Uzelac leaves the room [22:22:03] gcamaril joins the room [22:46:32] mcharlesr leaves the room [23:05:43] gcamaril leaves the room