aboutsummaryrefslogtreecommitdiffstats
path: root/channels/chan_sip.c
diff options
context:
space:
mode:
authordvossel <dvossel@f38db490-d61c-443f-a65b-d21fe96a405b>2010-08-13 18:58:49 +0000
committerdvossel <dvossel@f38db490-d61c-443f-a65b-d21fe96a405b>2010-08-13 18:58:49 +0000
commiteb0ec7df906d56b80aebffe0b711df6b5dba456e (patch)
tree5ccd2dac6a20bfd5d9d63e70011e4bba7b5a83d3 /channels/chan_sip.c
parent41bc431c20f57f24f174925a65d1db0dd827902d (diff)
Merged revisions 282236 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r282236 | dvossel | 2010-08-13 13:58:10 -0500 (Fri, 13 Aug 2010) | 23 lines Merged revisions 282235 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ........ r282235 | dvossel | 2010-08-13 13:54:53 -0500 (Fri, 13 Aug 2010) | 16 lines only do magic pickup when notifycid is enabled A new way of doing BLF pickup was introduced into 1.6.2. This feature adds a call-id value into the XML of a SIP_NOTIFY message sent to alert a subscriber that a device is ringing. This option should only be enabled when the new 'notifycid' option is set... but this was not the case. Instead the call-id value was included for every RINGING Notify message, which caused a regression for people who used other methods for call pickup. (closes issue #17633) Reported by: urosh Patches: chan_sip.txt uploaded by urosh (license ) blf_cid_issue.diff uploaded by dvossel (license 671) Tested by: dvossel, urosh, okrief, alecdavis ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@282237 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'channels/chan_sip.c')
-rw-r--r--channels/chan_sip.c33
1 files changed, 18 insertions, 15 deletions
diff --git a/channels/chan_sip.c b/channels/chan_sip.c
index 07d414397..e24681974 100644
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -11663,23 +11663,26 @@ static void state_notify_build_xml(int state, int full, const char *exten, const
ast_channel_unlock(caller);
caller = ast_channel_unref(caller);
}
+
+ /* We create a fake call-id which the phone will send back in an INVITE
+ Replaces header which we can grab and do some magic with. */
+ ast_str_append(tmp, 0,
+ "<dialog id=\"%s\" call-id=\"pickup-%s\" direction=\"recipient\">\n"
+ "<remote>\n"
+ /* See the limitations of this above. Luckily the phone seems to still be
+ happy when these values are not correct. */
+ "<identity display=\"%s\">%s</identity>\n"
+ "<target uri=\"%s\"/>\n"
+ "</remote>\n"
+ "<local>\n"
+ "<identity>%s</identity>\n"
+ "<target uri=\"%s\"/>\n"
+ "</local>\n",
+ exten, p->callid, local_display, local_target, local_target, mto, mto);
+ } else {
+ ast_str_append(tmp, 0, "<dialog id=\"%s\" direction=\"recipient\">\n", exten);
}
- /* We create a fake call-id which the phone will send back in an INVITE
- Replaces header which we can grab and do some magic with. */
- ast_str_append(tmp, 0,
- "<dialog id=\"%s\" call-id=\"pickup-%s\" direction=\"recipient\">\n"
- "<remote>\n"
- /* See the limitations of this above. Luckily the phone seems to still be
- happy when these values are not correct. */
- "<identity display=\"%s\">%s</identity>\n"
- "<target uri=\"%s\"/>\n"
- "</remote>\n"
- "<local>\n"
- "<identity>%s</identity>\n"
- "<target uri=\"%s\"/>\n"
- "</local>\n",
- exten, p->callid, local_display, local_target, local_target, mto, mto);
} else {
ast_str_append(tmp, 0, "<dialog id=\"%s\">", exten);
}