1.1 BLISS 1.1.1 Agenda Bashing / Status Update Presented by: Chairs
Jason unable to attend today. Design teams have been very active, but mostly NOT on the list. Call Park/Pickup - no teleconferences so no progress. 1.1.2 Automaric Call Handling Presented by: John Elwell Draft:draft-ietf-bliss-ach-analysis-02.txt Two topics at last meeting that we decided not to address at last meeting. Focused on addressing conflict between proxy and UA (don't want them to interfere with each other if they can both do ACH) - mostly focused on making sure UA doesn't interfere with proxies. Proposing that dataset draft (in SIPPING, but it's not a working group draft) is extended to include a parameter. Jonathan was very concerned that this is a huge hurdle - configuration framework isn't widely deployed today - just to support one configuration issue. Don't think people will do this. Francois - if this is a config option, just say that. If config framework ever takes off, we can add the parameter then. Mary - why invent another way when we've got the config framework? Jonathan - benchmark is phone and PBX from different figures just work - if you don't include a way to configure, is that helping interoperability? Martin - these devices already have a configuration capability, and most have ability to turn capabilities off and give control to the proxy. Already exists and is being used. Shida - so we don't need to standardize anything here? Jonathan - configure this property through whatever method your device supports. Lots of discussions on design team about getting information from UA for ACH at proxy. Down to busy/explicit rejection/silent rejection and local/global scope. 487 code use is different from what's in 3261. No recommendation for global silent rejection code value. 480 is suggested for DND in 3261, but this looks like overload with edge proxy indicating temporary lack of resources. Is global silent rejection a RUCUS topic? Francois - Is there a reason you want to reject globally silently? If this is nothing but SPIT, leave it for RUCUS or some follow-on. Is anyone concerned about overloading 480? Francois - don't have a concern about this, but if someone does, it's a 3261 issue and don't think it's caused interop problems. Don't worry about this unless we see a reason to worry. Don't alter meaning of 6xx response codes - if something global is required, use 4xx/5xx. Configuring ACH at the proxy from UA - XCAP considered to be overkill, Jonathan proposed REST - how to extend this, and where to standardize it? Not a lot of list discussion on this topic. Any issue in pursuing REST? Francois - REST is a trivial solution - good, but don't think it's only used by ACH - would be used by a number of drafts. Would need to set up a registry. Is this limited in scope to BLISS? Jonathan - suggested this instead of XCAP because REST is deployed all over the network - Web 2.0, just use the framework, who needs a registry? Scott - support this in general, but don't generalize into a framework until we're sure we have something that works. There are lots of PBX features people want to support from phone-tops. Think we should focus on example first and get it working - then generalize. Mary - go ahead and take a higher view, use this as a use case. Jonathan - "agile process" - have next rev of document, look at it and decide. Don't think I know what a framework for this looks like. XCAP disappears in a puff of smoke when you say "REST". One step at a time. Allen - seems reasonable for trivial things - won't you get into situations where you need to read? That's actually GET. This is running on the Internet for way more complicated stuff than this. Keith - haven't decided what parameter to set yet, so need to understand scope first. Jonathan - the world has moved on here. We need to wake up and smell the coffee. Concept is similar and doesn't have XCAP's problems. Keith - don't agree with the way forward - should be a different document that makes a case for a different configuration framework. Don't want to specify exactly what ACH is - very service-provider-specific, not what we are trying to do in the IETF. Christer - may not have common understanding of what ACH is. Martin - we know how to turn these parameters off and on - look at that, start simple. Jonathan - just agree on parameters and interpretation by the process. If we can't figure out the parameters for minimal ACH, discussion of framework is pointless. 1.1.3 Call Completion Presented by: Denis Alexeitsev Draft:draft-ietf-bliss-call-completion-02.txt Suspend and resume procedures proposed to use PUBLISH. Proposing CC event body. How to correlate INVITE and SUBSCRIBE? Intermediate proxies might change call-ID. Adam - if you change the call-ID, you're not a proxy, and we shouldn't bend over backwards to accommodate SBCs. Jonathan - reality is that this is an unreliable header. Thought we had figured out how to do this without adding state (which is necessary from security perspective). Keith - what are you correlating? Initial INVITE and SUBSCRIBE. Jonathan - I thought we needed this because you can't ask to be queued for call completion if you haven't called the person yet. Keith - that's in ISDN. Jonathan - security. if not, I can send arbitrary subscribes. Keith - this is basically setting up a call for when a user is available Jonathan - you either have to keep state or use a URI as a token - this is an authorization question. Keith - you don't need to create state. (some "yes"/"no" exchange happened about here). How to route the suspension PUBLISH to the appropriate monitor? Send within the SUBSCRIBE dialog? Use a GRUU received in the NOTIFY body? Jonathan - defer this feature - consumes resources in called party domain for benefit of calling party - already a disincentive for deployment. Not familiar with PSTN side, but if this can be rejected on PSTN side, should also reject it on SIP side. Don't think this is mandatory - people poll for this today. Francois - getting complicated because we're trying to interwork with ISDN, I think it's implemented the same way as ISDN, we're getting complicated while spinning our wheels and making this less likely to be deployed. Adam - not disagreeing with Jonathan/Francois - but if we do go down this path, GRUU is the way we're headed. I expect to press for deprecating anything except GRUUs in Contact header when we rev 3261. Hums - · suspend/resume removed from the spec? · unsubscribe and subscribe? This was silent. · Event packages? This was silent Trying again · Keep suspend/resume? Sounded pretty evenly divided (between keep/don't keep) - will take to the list. Adam - can we do basic feature and do extensions later? Nail down 99-percent use case. This is minor capability that gives us half the complexity in the draft. John - people can enhance later, this is taking a lot of time to produce, keep it as simple as we can, otherwise we'll never finish anything. If you want the callback feature, you probably want this finished quickly. 1.1.4 Line Sharing Presented by: Alan Johnston Draft:draft-johnston-bliss-mla-req-02.txt Three methods (INVITE overlap is new). Need to pick one and go forward. Most UAs don't have to implement any of the methods (don't have multiple line appearances). Adam - no matter what method we pick, something in the middle has to understand MLA. Implementation complexity is the same. PUBLISH/NOTIFY has deployments, design team supports it. Floor control is cleaner architecturally but has no supporters. INVITE stretches overlap dialing but doesn't require protocol work. Jonathan - don't agree with 3265 violation. PUBLISH/NOTIFY is what people are doing. Do what people are doing if you want interoperability. Francois - list so far is nobody likes BFCP, support for PUBLISH/NOTIFY, was thinking INVITE was OK but don't like it now, looking at the call flows. Does proxy decide a line has to be seized, or is it the UA? Server would ask client to say "tell me when you're in 100 state". Not clear what the intent was, just jumped into mechanisms. Regardless of choice, tempted to say that INVITE is least attractive of three choices. Hum - strongly favored PUBLISH/NOTIFY mechanism. 1.1.5 History Info and Diversion Interworking Presented by: Xavier Marjou Draft:draft-mohali-diversion-history-info-00.txt Two solutions - Diversion header (proprietary but widely deployed) and History-Info (RFC 4244, also adopted by other SDOs but not widely implemented or deployed). Almost no equipment supports History-Info. Francois - History-Info isn't Diversion, we're sabotaging History-Info by dumbing it down, so it won't work for anything except PSTN interworking). My company is guilty, too. Adding a parameter (as Jonathan suggests) is only way I see to do this that will work. Mary - don't disagree - 4458 isn't replacing History-Info. We started out from Diversion header, we have something general, if operators want this, let them pay vendors to develop - they aren't paying to develop History-Info. Ben - we've decided not to go the Diversion route many times. Martin - there are many SIP phones that support Diversion and won't be upgraded. We're going to be receiving this header for a long time. We need a way to provide interworking - that will help carriers decide to deploy History-Info. Steve - agree. Diversion is much wider than ISDN these days. Big bang scenarios never work - you have to have a transition story. Jean-Francois - Diversion is there, widely deployed, in some cases it's what people need. Unanimous feedback from several operators in cable space was "no, Diversion is there and it's good enough". ??? - Proposal is not to standardize Diversion header, it's to standardize a mapping mechanism. We have this problem today. We may discuss, but at least the requirements are there. Robert - apologize for the poke, but if you ask vendors to implement a non-standard, the pain should be yours. But let me ask - draft is proposing bi-directional mapping. Why do we need History-Info-to-Diversion mapping? Mary - we implemented both, why can't you carry both and switch over to 4458 for interworking? In some cases, we do preserve both. Francois - not bidirectional, there are things you can't do in PSTN, so you lose information (forking in SIP, etc.). History-Info tells you what's in SIP, not what happens behind a gateway. If you merge them, you're changing History-Info's goal and it becomes unreliable at describing what happened to the request. If we're going to do this, why do we need History-Info in the first place? Jean-Francois - but you have a good representation of what carriers are saying in the draft. Problem is that operators need to deploy with software that's been tested in their labs and is available, at some point in time. We tried to get people to upgrade. It's not going to work. Some operators are deploying new SIP services and will require History-Info support, but they will have to deal with Diversion for a long time. Christer - this reminds me of INFO discussion. customers didn't ask for Diversion because it's better, they ask because that's what out there today. Maybe mapping isn't right term, but we need interworking. We lose information when we interconnect today. Martin - we have a fair amount of wireline carriers globally and in the US on this draft. If you think every vendor's product is compliant to these RFCs, you're nuts. There are TAs, SIP Phones, even IP-PBXes that do Diversion - if we don't go this way, we'll just fix the problems on an SBC. Mary - we should do an informational spec - not standards-track. Hadriel - if we do this mapping, we get SOME information, but if we don't, we get NO information. Jonathan - agree with many folks, including Martin(!). We can't just change SIP when we have a new idea. Agnostic on details here, but discussion about this topic is the right thing to do - not doing it is like ignoring NATs. Not just a service-provider problem, it's also deployed in enterprise networks. Jean-Francois - rough consensus and running code. Francois - this is surreal. We're lobotomizing History-Info to do this mapping thing. There is a problem. Best way is to do this in parallel (with a real History-Info definition). If group doesn't think that's a good idea, we have to do transition in non-destructive way to show this is a redirection in the classical sense. Keith - draft is about interop - if it's supposed to be migration, you need to say so in the draft. Robert - no one has answered my question - asking again. Can see mapping in one direction. Is there a need for a bi-directional mapping? Martin - IP-PBX call center, may have multiple redirections. Robert - that's scale = 1, not scale 100,000 and nothing is making History-Info now - what's the chances it will start showing up? Hadriel - seeing History-Info in peering situations (but they may be mapping it right back to Diversion). Eric - draft is expired and five years old. Spencer - this is the kind of thing Informational publication is for.
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
