1. 1 IETF 72 BLISS WG meeting draft-ietf-bliss-ach-analysis-02 John Elwell

2. 2 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

3. 3 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

4. 4 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?

5. 5 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

6. 6 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?