From b18d14eda52f1d9cd8bfc9aa38d7293a3a11b692 Mon Sep 17 00:00:00 2001
From: Richard Fuchs <rfuchs@sipwise.com>
Date: Wed, 23 Oct 2013 12:23:50 -0400
Subject: [PATCH] Implement non-fatal warnings in NG replies and use them in
 "delete"

Closes: #12
---
 README.md     | 13 +++++++++++--
 daemon/call.c | 17 +++++++++++++++--
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/README.md b/README.md
index 601bfe13b..017c12dbb 100644
--- a/README.md
+++ b/README.md
@@ -462,7 +462,8 @@ a string and determines the type of message. Currently the following commands ar
 The response dictionary must contain at least one key called `result`. The value can be either `ok` or `error`.
 For the `ping` command, the additional value `pong` is allowed. If the result is `error`, then another key
 `error-reason` must be given, containing a string with a human-readable error message. No other keys should
-be present in the error case.
+be present in the error case. If the result is `ok`, the optional key `warning` may be present, containing a
+human-readable warning message. This can be used for non-fatal errors.
 
 For readabilty, all data objects below are represented in a JSON-like notation and without the message cookie.
 For example, a `ping` message and its corresponding `pong` reply would be written as:
@@ -618,7 +619,15 @@ The reply message is identical as in the `offer` reply.
 ----------------
 
 The `delete` message must contain at least the keys `call-id` and `from-tag` and may optionally include
-`to-tag` and `via-branch`, as defined above.
+`to-tag` and `via-branch`, as defined above. It may also optionally include a key `flags` containing a list
+of zero or more strings. The following flags are defined:
+
+* `fatal`
+
+	Specifies that any non-syntactical error encountered when deleting the stream
+	(such as unknown call-ID) shall
+	result in an error reply (i.e. `"result": "error"`). The default is to reply with a warning only
+	(i.e. `"result": "ok", "warning": ...`).
 
 The reply message may contain additional keys with statistics about the deleted call. Those additional keys
 are the same as used in the `query` reply.
diff --git a/daemon/call.c b/daemon/call.c
index 548ebff41..bc713f446 100644
--- a/daemon/call.c
+++ b/daemon/call.c
@@ -2722,6 +2722,8 @@ const char *call_answer_ng(bencode_item_t *input, struct callmaster *m, bencode_
 
 const char *call_delete_ng(bencode_item_t *input, struct callmaster *m, bencode_item_t *output) {
 	str fromtag, totag, viabranch, callid;
+	bencode_item_t *flags, *it;
+	int fatal = 0;
 
 	if (!bencode_dictionary_get_str(input, "call-id", &callid))
 		return "No call-id in message";
@@ -2730,8 +2732,19 @@ const char *call_delete_ng(bencode_item_t *input, struct callmaster *m, bencode_
 	bencode_dictionary_get_str(input, "to-tag", &totag);
 	bencode_dictionary_get_str(input, "via-branch", &viabranch);
 
-	if (call_delete_branch(m, &callid, &viabranch, &fromtag, &totag, output))
-		return "Call-ID not found or tags didn't match";
+	flags = bencode_dictionary_get_expect(input, "flags", BENCODE_LIST);
+	if (flags) {
+		for (it = flags->child; it; it = it->sibling) {
+			if (!bencode_strcmp(it, "fatal"))
+				fatal = 1;
+		}
+	}
+
+	if (call_delete_branch(m, &callid, &viabranch, &fromtag, &totag, output)) {
+		if (fatal)
+			return "Call-ID not found or tags didn't match";
+		bencode_dictionary_add_string(output, "warning", "Call-ID not found or tags didn't match");
+	}
 
 	bencode_dictionary_add_string(output, "result", "ok");
 	return NULL;