Notes by Spencer
/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 (dont want them to interfere with each other if they can both do ACH) mostly focused on making sure UA doesnt interfere with proxies.
Proposing that dataset draft (in SIPPING, but its not a working group draft) is extended to include a parameter.
Jonathan was very concerned that this is a huge hurdle configuration framework isnt widely deployed today just to support one configuration issue. Dont 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 weve got the config framework?
Jonathan benchmark is phone and PBX from different figures just work if you dont 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 dont 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 whats 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 dont have a concern about this, but if someone does, its a 3261 issue and dont think its caused interop problems. Dont worry about this unless we see a reason to worry.
Dont 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 dont think its 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 dont generalize into a framework until were 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. Dont 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 wont you get into situations where you need to read?
Thats actually GET
This is running on the Internet for way more complicated stuff than this.
Keith havent 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 doesnt have XCAPs problems.
Keith dont agree with the way forward should be a different document that makes a case for a different configuration framework.
Dont 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 cant 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, youre not a proxy, and we shouldnt 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 cant ask to be queued for call completion if you havent called the person yet.
Keith thats 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 dont 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. Dont think this is mandatory people poll for this today.
Francois getting complicated because were trying to interwork with ISDN, I think its implemented the same way as ISDN, were 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 were 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/dont 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 well 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 appearance "seizure" methods (INVITE overlap is new). Need to pick one and go forward.
Most UAs dont have to implement "seizure" or any of the methods (they still have multiple line appearances but don't need to do "seizure").
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 doesnt require protocol work.
Jonathan dont 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 dont 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 youre 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 isnt Diversion, were sabotaging History-Info by dumbing it down, so it wont 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 dont disagree 4458 isnt replacing History-Info. We started out from Diversion header, we have something general, if operators want this, let them pay vendors to develop they arent paying to develop History-Info.
Ben weve decided not to go the Diversion route many times.
Martin there are many SIP phones that support Diversion and wont be upgraded. Were 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 its what people need. Unanimous feedback from several operators in cable space was no, Diversion is there and its good enough.
??? Proposal is not to standardize Diversion header, its 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 cant you carry both and switch over to 4458 for interworking?
In some cases, we do preserve both.
Francois not bidirectional, there are things you cant do in PSTN, so you lose information (forking in SIP, etc.). History-Info tells you whats in SIP, not what happens behind a gateway. If you merge them, youre changing History-Infos goal and it becomes unreliable at describing what happened to the request. If were 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 thats been tested in their labs and is available, at some point in time. We tried to get people to upgrade. Its 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 didnt ask for Diversion because its better, they ask because thats what out there today. Maybe mapping isnt 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 vendors product is compliant to these RFCs, youre nuts. There are TAs, SIP Phones, even IP-PBXes that do Diversion if we dont go this way, well 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 dont, we get NO information.
Jonathan agree with many folks, including Martin(!). We cant 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, its also deployed in enterprise networks.
Jean-Francois rough consensus and running code
Francois this is surreal. Were 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 doesnt think thats 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 its 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 thats scale = 1, not scale 100,000 and nothing is making History-Info now whats 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
Notes by Keith
Text below does include text of the slides for context.
Keith
Monday 15:20 - 17:20 BLISS
==========================
Remote Logistics
We have mp3 Feed: Speak into the Mic!
http://www.ietf.org/audio//ietf721.m3u
Jabber
Server: jabber.ietf.org
Room: bliss
Logs: http://www.ietf.org/meetings/ietf-logs/bliss/
Meeting Materials (Presentations, Agenda, etc.)
https://datatracker.ietf.org/meeting/72/materials.html
Supplemental Web Site
http://www.bliss-ietf.org/
Scribes and Transcribes
2 Note Taker
Jabber Scribe
Agenda
Agenda Bash/Status (Chairs) - 10 min
Diversion and History-Info interwokring (Xavier) - 5 min
Automatic Call Handling (John) - 25 min
Call Completion (Martin) - 25 min
MLA (Alan) - 35 min
Last minute change in the agenda
Mary asked to move Diversion header stuff to end of the agenda. Moved.
Goals and Milestones
Current Proposal Milestone
2008 April 2008 Dec Problem Statement
2008 April 2008 Dec Automatic Call Handling
2008 August 2008 Dec Call Completion
2008 August 2009 Feb Call Park/Pick Up
2008 October 2009 Feb Line Sharing
Behind on milestones so will be changing the milestones.
Automatic Call Handling (John) - 25 min
-----------------------------------------
Measures to be taken (1)
Addressing conflict between UA and proxy
The present draft proposes configuration of UAs to get them to defer to
a proxy for ACH
Does not mandate a particular configuration method, but suggests the
configuration framework be one method
Proposes draft-petrie-sipping-voip-features-dataset (assuming it is
adopted as work item) be enhanced to include this parameter
Open issue over whether one parameter is sufficient or if several are
needed (to cover different conditions)
PROPOSAL - go ahead and ask SIPPING to add single parameter to
voip-features-dataset
Jonathan: Expressed concern that it creates a large gapo for vendors to
jump over to allow implementation. Config framework is not yet widely
used.
Francois: Should address this config option and say that (leaves
mechanism open which could use config framework).
Mary: If we are going to invent another way, then why have we done
config framework.
Christer:
What level of requirement does the statements mean.
Martin:
Editor thought he had some ideas for rewriting this text. Text will
state something along lines of "For whatever configuration mechanism
you use in your UA, it will need to be able to configure these settings.
Measures to be taken (2)
Obtaining information from UA for ACH at proxy
Proposes conditions:
busy
explicit rejection
silent rejection
Proposes scopes:
local (only current branch and other branches to same user, but not
voicemail or other users)
everything, including voicemail and other users
Measures to be taken
(2, continued)
Proposed response codes
Busy / local: 486
Explicit rejection / local: 480
Silent rejection / local: 487 (i.e., as if proxy had issued CANCEL
request)
Busy / global: 600
Explicit rejection / global: 603
Silent rejection / global: No code recommended
486/480/600/603 may be accompanied by Retry-After
Open issue over 480 for explicit rejection / local
(RFC 3261 suggests this for DND, but concern about overload with edge
proxy indicating temporary lack of resources)
Open issue over need for code for silent rejection / global
Perhaps for SPIT, but is this more a RUCUS topic?
Francois: Reason missing code is in here is for reasons of symmetry
rather than any real use case.
John: Anti SPIT is the real use case. Leave for now, and if someone
wants to define in the SPIT case, then it is up to that work to do it.
John: Is 480 overloaded?
Francois: Does not have a concern with this. Thinks that it is
overloaded, but the cause of this problem is the contents of RFC 3261.
Measures to be taken (3)
Scope of 6xx response codes
Propose not to alter present meaning of 6xx (truly global)
If something less than global required, then use 4xx/5xx
John: Consider that 6xx really should mean everything.
Measures to be taken (4)
Configuring ACH at the proxy from the UA
XCAP (some consider this overkill)
Proposal from Jonathan Rosenberg for a trivial REST Representational
State Transfer) interface, e.g:
POST http://server.com/joe/profile/callforwarding?value=true
Would need to be extensible
How would this be standardised, and where?
Lack of list discussion on this topic
Any interest in investigating a REST-based solution?
Jonathan wants to use REST.
Francois wants to do this.
Keith: Need to define what needs to be configured.
John: Concern about keeping what needs to be configured flexible.
Conclusion: Will define more data on what needs to be configured in next
draft.
Call Completion (Martin) - 25 min
---------------------------------
Changes from the previous version
Major revision of the procedures under editorial and clarification
aspects.
The usage of PUBLISH was proposed for suspend and resume procedures.
Proposal of header based CC body.
Dialog correlation between initial INVITE and CC SUBSCRIBE has been
discussed, but there are still open issues.
Suspend and resume procedures
discussions on implicit solution using un-SUBSCRIBE and re-SUBSCRIBE vs.
explicit solution using PUBLISH to suspend and resume queue entries
state management issue when using un-SUBSCRIBE for suspension: queue has
to be maintained at the CC monitor while UA-A has un-subscribed and
unallocated it's resources;
potential DoS vulnerability regarding the CC monitor
using PUBLISH maintains logic dialog between CC agent und CC monitor
also on SIP level: UA-A is in the SUBSCRIBE dialog with the CC monitor
even while suspended;
producing a DoS in such environment would require much more resources at
the UA side
Grammar of the CC event body
proposal for a header based solution similar to RFC 3842
sufficient to transfer information needed for call-completion
call-completion = +(cc-header CRLF)
cc-header = cc-state / cc-service-retention/ cc-URI
cc-state = "state" HCOLON ( "queued" / "ready" )
service-retention = "service-retention" HCOLON "true "
cc-URI = "URI" HCOLON (name-addr / addr-spec) *(SEMI generic-param)
Open issue 1
How to correlate the initial INVITE and the SUBSCRIBE for CC?
Problem:
intermediate proxies might change call-id
Solutions:
consideration of the From header for determination of the event
definition of a token for CC
usage of draft-loreto-sipping-context-id-requirements
Adam: Should not solve the problem for entities which change call id.
Keith: Checked that this was the correlation between the original failed
request and the subscribe. Why do we need the correlation in the first
place. Is there anything harmful in a request to start a call when the
resources are available.
Jonathan thinks this is to save state that would otherwise be required.
Open issue 2
How to route the suspension PUBLISH to the appropriate monitor?
Problem:
several CC monitors can serve the callee
Solutions:
sending it within the SUBSCRIBE dialog
use a GRUU received in the NOTIFY body
Hum on whether suspend / resume should stay in the draft or be removed.
Not conlusive.
Example Part 1
[figure]
Example Part 2
[figure]
To do
Solve the open issues.
Render the queue model more precisely.
Specify the service retention feature.
Revise the examples section.
Define timers and timer values for the CC service
Questions / Comments
MLA (Alan) - 35 min
-------------------
Slide 1
Slide 2
Slide 3
Slide 4
Slide 9:
Francois: Should try and get some idea of the requirement befofre we
make the decision on which solution to adopt. Need to make sure we
solve the right problem.
Alan: If don't need the seizure we don't need anything here.
Martin: Wants the PUBLISH/NOITIFY as the more interoperable approach.
Mary: Nice if we had made a decision to use a cleaner approach to do
something.
Adam: Most interoperable by using PUBLISH/NOTIFY.
Diversion and History-Info interwokring (Xavier) - 5 min
--------------------------------------------------------
Mapping and interworking of Diversion information between
Diversion and History-Info Headers in the SIP
draft-mohali-bliss-diversion-history-info-00
M. Mohali (France Telecom), S. Norreys (British Telecom),
J. Van Geel (Belgacom), M. Dolly (ATT),
F. Silva (Portugal Telecom), G. Sciortino, C. Amenta (Italtel)
Context about Call-Forwarding
Need to transport call forwarding information to a UA (regular user,
voicemail, call-center, or other downstream element)
2 solutions
Diversion header
Proprietary solution documented in draft-levy-sip-diversion
Widely implemented and deployed
History-Info header
IETF standard solution (RFC4244), also adopted by other standardization
bodies (e.g. 3GPP and TISPAN)
Not yet widely implemented nor deployed
In order to migrate towards the History-Info solution, there is a need
to support interworking between History-Info and Diversion for backward
compatibility.
Interworking Problem
The two headers differ in scope, syntax and semantics
History-Info:
<sip:proxyP1>; index=1,
<sip:userB>; index=1.1
<sip:userC>; cause=302; index=1.1.1
<sip:userD>; cause=408; index=1.1.1.1
Diversion:
C; reason= no-answer; counter=1,
B; reason= unconditional; counter=1
Rules should be defined to ensure that manufacturers apply the same
interworking procedures.
Lack of clear mapping between both headers results in significant
interoperability issues and therefore delay widespread implementation of
the History-Info header.
Proposal
Map call forwarding information contained in a Diversion header into a
History-Info header, and vice versa.
Make some recommendations:
For example: "When the Diversion header is mapped into a History-Info
header, the Diversion header MUST be removed".
Francois: Problem is that History-Info does not map to diversion header
as History-Info is not an implementation of the ISDN. If we take a dumb
approach to interworking, then we end up dumbing down History-Info. If
want to do somethiong useful, then would need to add a parameter to
history info that essentially tagged entries. Proposed to stick with RFC
4458 and do the mapping as described in that document.
Mary: Should never rip out the History-Info. Should send both forward if
want to implement both.
Ben: Sceptical of a mapping between something we have standardised and
something proprietary.
Martin: Will be receiving diversion header for a long time in the
future.
Steve Norreys: Need a migration scenario.
Jean-Francois: Diversion is there and widely deployed. Operators in
cable space want to keep diversion.
???: Proposal is not to standardise the diversion header, but to migrate
towards a mechanism that uses the History-Info.
Robert: If you have asked vendors to build something that is not
standard, and then want interworking, the pain should be with the
non-standard vendors.
Mary:
Francois: Main problem with proposal is that it breaks History-Info. It
is not bidirectional. If try to merge them, then changing History-Info
at the original level.
Jean-Francois: Operators are on the author list.
Christer:
INFO disucssion.
Martin: Carriers do not want to do interworking.
Mary: Should not do standards track or informational. When implementing
tried to build off packetcable specs.
Hadriel: Is there an interoperability to be standardised. However
Diversion is the defacto standard.
Jonathan: Agrees partly with previous speakers. Agnostic on details. How
to do migration is important.
Jean Francois: Go with running ocde and rough concensus. Diversion
headrer as running code.
Francois: Implementation experience internally.
Mary: Need to focus on new stuff and not on the proprietary stuff.
Keith: Does not talk about migration only mapping. Also if IETF is going
to interoperate, need to cover issue with RFC 3427 and how this is
documented.
Robert: Not had his question answered. What is the deployment scenario
where need to map.
Martin:
Hadriel: Peering arrangements force some conversion.
Eric: Would be better writing a document on usages of History-Info.
Hadriel: There is some line where things cross a line.