Hi folks,<br><br>I've just updated my trunk install and noticed some odd behaviour with connected line updates... Every single file played sends connected line updates...<br><br>e.g. for calls to voicemail, I set CONNECTEDLINE to VM (Eng) <*89><br>
previous behaviour was that it sent the RPID as an update and the phone displayed VM (Eng) <*89> for the entire call<br>current behaviour is that the string is sent in the RPID as an update and then every single sound file played triggers a further update, first sent as an update and all subsequent ones as invites...<br>
i.e. (from sip history)<br>11. ConnectedLine Called party is now vm-password <vm-password><br>12. TxReqRel UPDATE / 102 UPDATE - UPDATE<br>15. ConnectedLine Called party is now vm-youhave <vm-youhave><br>
16. TxReqRel INVITE / 103 INVITE - INVITE<br>19. ConnectedLine Calling party is now 1 <1><br>20. TxReqRel INVITE / 104 INVITE - INVITE<br>23. ConnectedLine Calling party is now vm-Old <vm-Old><br>
24. TxReqRel INVITE / 105 INVITE - INVITE<br>27. ConnectedLine Calling party is now vm-message <vm-message><br>28. TxReqRel INVITE / 106 INVITE - INVITE<br>31. ConnectedLine Calling party is now vm-onefor <vm-onefor><br>
32. TxReqRel INVITE / 107 INVITE - INVITE<br>35. ConnectedLine Calling party is now vm-Old <vm-Old><br>36. TxReqRel INVITE / 108 INVITE - INVITE<br>39. ConnectedLine Calling party is now vm-messages <vm-messages><br>
40. TxReqRel INVITE / 109 INVITE - INVITE<br>43. ConnectedLine Calling party is now vm-opts <vm-opts><br>44. TxReqRel INVITE / 110 INVITE - INVITE<br>47. ConnectedLine Calling party is now vm-helpexit <vm-helpexit><br>
48. TxReqRel INVITE / 111 INVITE - INVITE<br><br>This doesn't seem to be intended behaviour...<br><br>The cause of these updates is a change to main/file.c that seems to have sneaked in from somewhere...<br><br>
# svn diff <a href="http://svn.digium.com/svn/asterisk/trunk/main/file.c@203802">http://svn.digium.com/svn/asterisk/trunk/main/file.c@203802</a> <a href="http://svn.digium.com/svn/asterisk/trunk/main/file.c@204413">http://svn.digium.com/svn/asterisk/trunk/main/file.c@204413</a><br>
Index: file.c<br>===================================================================<br>--- file.c (revision 203802)<br>+++ file.c (revision 204413)<br>@@ -320,6 +320,7 @@<br> free(f->filename);<br>
if (f->realfilename)<br> free(f->realfilename);<br>+ ast_free(f->open_filename);<br> if (f->fmt->close) {<br> void (*closefn)(struct ast_filestream *) = f->fmt->close;<br>
closefn(f);<br>@@ -472,6 +473,7 @@<br> s->fmt = f;<br> s->trans = NULL;<br> s->filename = NULL;<br>+ s->open_filename = ast_strdup(fn);;<br>
if (s->fmt->format & AST_FORMAT_AUDIO_MASK) {<br> if (chan->stream)<br> ast_closestream(chan->stream);<br>
@@ -826,7 +828,30 @@<br><br> int ast_applystream(struct ast_channel *chan, struct ast_filestream *s)<br> {<br>+ struct ast_party_connected_line connected;<br>+ char *fn;<br>+<br>+ ast_channel_lock(chan);<br>
+ ast_party_connected_line_set_init(&connected, &chan->connected);<br>+ if (ast_strlen_zero(chan->connected.id.number)) {<br>+ connected.id.number = ast_strdupa(chan->exten);<br>
+ }<br>+ ast_channel_unlock(chan);<br>+<br>+ fn = ast_strdupa(s->open_filename);<br>+ if ((fn = strrchr(fn, '/'))) {<br>+ char *dot;<br>+ *fn++ = '\0';<br>
+ if ((dot = strrchr(fn, '.'))) {<br>+ *dot = '\0';<br>+ }<br>+ }<br>+ connected.id.number = <a href="http://connected.id.name">connected.id.name</a> = fn;<br>
+<br>+ ast_channel_update_connected_line(chan, &connected);<br>+<br> s->owner = chan;<br>+<br> return 0;<br> }<br><br>This appears to have sneaked in with the addons merge...<br><br>------------------------------------------------------------------------<br>
r204413 | russell | 2009-07-01 00:40:38 +0800 (Wed, 01 Jul 2009) | 12 lines<br>...<br>M /trunk/main/file.c<br>...<br>Move Asterisk-addons modules into the main Asterisk source tree.<br><br>Someone asked yesterday, "is there a good reason why we can't just put these<br>
modules in Asterisk?". After a brief discussion, as long as the modules are<br>clearly set aside in their own directory and not enabled by default, it is<br>perfectly fine.<br><br>For more information about why a module goes in addons, see README-addons.txt.<br>
<br>chan_ooh323 does not currently compile as it is behind some trunk API updates.<br>However, it will not build by default, so it should be okay for now.<br><br>------------------------------------------------------------------------<br>
<br>Anyone know where this came from? Was it intended or was it perhaps a local debug version that was accidentally included in a checkin?<br><br>Raised in the bug tracker as issue 15657...<br><br>Thanks,<br><br>d<br>