dect
/
asterisk
Archived
13
0
Fork 0
Code Releases Activity

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
This commit is contained in:
dvossel 2010-08-13 18:58:49 +00:00
parent 41bc431c20
commit eb0ec7df90
1 changed files with 18 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
channels/chan_sip.c
View File

@ -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);
}