Ticket #97 (closed Enhancement: Fixed)
dialog-rules
| Reported by: | adigeo | Owned by: | adigeo |
|---|---|---|---|
| Priority: | Minor | Milestone: | OpenXCAP 1.2.0 |
| Component: | XCAP applications | Version: | trunk |
| Severity: | Non-critical | Keywords: | |
| Cc: |
Description
Support dialog rules auid meant to provide an authorization policy for Event dialog
Change History
comment:2 Changed 3 years ago by adigeo
- Owner set to adigeo
- Status changed from new to accepted
If there is a schema for filtering we could apply it. Do you know about such schema?
It then must be supported in the PA, xcap server can only validate the content.
comment:3 Changed 3 years ago by ibc
I don't know about an existing schema for it. RFC 4235 talks about "local policy" XDD
comment:4 Changed 3 years ago by adigeo
One way to have a delimitation for how much information is revealed si to:
- For basic call status information one can use simply Event=presence and set the activity to 'On the phone', no other detail is available
- For full dialog state, use Event=dialog where all dialog info is available
By allowing people to by Notified for these two different events we can have enough flexibility with a minimum overhead of maintaining the access lists.
comment:5 Changed 3 years ago by ibc
I don't like too much your proposal. Usually, softphones implements presence subscription and deskphones dialog subscription. I don0t know yet a *phone implementing both.
comment:6 Changed 3 years ago by adigeo
It is a matter of configuration how you use the system as a whole so you may change its behaviour through configuration without having to agree or disagree with me.
A hardware phone has no policy management anyway, it expects a PBX to drive that policy. What I wrote applies for a device that supports both event types and how to handle them.
Will it be a basic "allowed"/"blocked" policy?
RFC 4235 says that the presence server (NOTIFY composer) could filter some info about the dialog depending on "local" policy. For example: Alice is allowed to monitor calls from/to Bob, but she will not receive info about the caller/called (so the NOTIFY will not contain info about caller/callee SIP URI or display name).