110 likes | 213 Views
IETF 69 BLISS WG meeting. Automated Handling draft-elwell-bliss-dnd-00. Overview. The Automated Handling topic in the BLISS charter is intended to cover features like DND, CFU, CFNA The present draft addresses only DND (identified as a specific topic in an earlier charter proposal)
E N D
IETF 69 BLISS WG meeting Automated Handling draft-elwell-bliss-dnd-00
Overview • The Automated Handling topic in the BLISS charter is intended to cover features like DND, CFU, CFNA • The present draft addresses only DND (identified as a specific topic in an earlier charter proposal) • Aims of this session: • Discuss direction to be taken for DND • Discuss expansion to address the wider automated handling topic
DND – problems to be solved? • Indicating a DND condition to a proxy (which might take specific action, such as forward to voicemail) • Scope of such an indication (use of 6xx) • Indicating a DND condition to a caller when call is rejected because of DND • Indicating a DND condition in presence
Indicating DND to a proxy • Needs to be an explicit indication if proxy is to take specific action (reason phrase not sufficient), e.g.: • 480 • 480 + retry • 603 • New 4xx • New 6xx
Scope of 6xx • If use 603 or new 6xx, how should this affect forking and retargeting: • Do not fork or retarget to any other contacts for this AoR (cancel any existing branches)? • Do not fork or retarget to any other contacts for any AoR (cancel any existing branches)? • Is this something that needs fixing in general for 6xx responses (RFC 3261 not clear)?
Indicating DND condition to caller • Are requirements different from indicating DND to proxy? • May wish to hide the condition from a caller: • use 486 Busy Here, perhaps with Retry-After • use 180 followed by 408 • Where condition is to be indicated, reason phrase could be used (but language problem) • Is it sufficient just to rely on proxy to conceal information from caller (e.g., by changing response code) if policy is to reject call rather than forward to voicemail etc.? • HERFP problem – prioritisation of DND response compared with responses from other branches
Indicating DND condition in presence • Is there any desire to extend RPID to give an explicit indication of DND? • Would this be in conjunction with “open” rather than “closed”?
DND – problems that don’t need solving? • Do we need SIP means for setting / clearing DND at a proxy? • Assumed not • Do we need SIP means for overriding DND? • Assumed RFC 4412 (resource priority) could be used without further standardisation
Similarity between DND and other automated handling features (CFU/CFNR) • DND can result in forwarding • DND and forwarding can both be initiated by UAS or proxy • Initiation by proxy requires some means of making the proxy aware of the condition and action to be taken
Differences between DND and other automated handling features (CFU/CFNR) • DND does not necessarily result in forwarding (can lead to simple rejection) • Forwarding as result of DND can be initiated at a different place from DND itself (UAS initiates DND / proxy initiates forwarding) • DND has problems to be solved concerning how to indicate the condition in SIP and in presence • Unclear what problems (if any) need to be solved for CFU/CFNR
Proposal concerning expansion to cover automated handling in total • The differences between DND and CFU/CFNR seem to outweigh the similarities • although CFU/CFNR not yet investigated • Therefore makes sense to treat DND and forwarding as different functional primitives • DND can, of course, lead to forwarding. This is just one example of many potential interactions between functional primitives.