diff options
| author | file <file@f38db490-d61c-443f-a65b-d21fe96a405b> | 2009-05-05 18:27:59 +0000 |
|---|---|---|
| committer | file <file@f38db490-d61c-443f-a65b-d21fe96a405b> | 2009-05-05 18:27:59 +0000 |
| commit | a65bdbcf0eb10c131edf02f00ab04cc5d9c4fac2 (patch) | |
| tree | d496156292d5356cd3a3e331ff394cb74110c821 /main | |
| parent | d107fe05ca9c046c51893a61b4d40c90fbf7aa0e (diff) | |
Merged revisions 192462 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
................
r192462 | file | 2009-05-05 15:23:58 -0300 (Tue, 05 May 2009) | 15 lines
Merged revisions 192454 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r192454 | file | 2009-05-05 15:22:27 -0300 (Tue, 05 May 2009) | 8 lines
Fix an incorrect assumption that certain values on the channel will always exist when they may not.
The CDR code involved with bridges wrongly assumed that the currently executing application and data
values will always exist. It is possible for this to be false when call forwarding is involved.
(closes issue #14984)
Reported by: gincantalupo
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@192480 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'main')
| -rw-r--r-- | main/features.c | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/main/features.c b/main/features.c index 092f29d25..85aaa1e0f 100644 --- a/main/features.c +++ b/main/features.c @@ -2493,16 +2493,16 @@ int ast_bridge_call(struct ast_channel *chan,struct ast_channel *peer,struct ast ast_set_flag(chan_cdr, AST_CDR_FLAG_MAIN); ast_cdr_update(chan); bridge_cdr = ast_cdr_dup(chan_cdr); - ast_copy_string(bridge_cdr->lastapp, chan->appl, sizeof(bridge_cdr->lastapp)); - ast_copy_string(bridge_cdr->lastdata, chan->data, sizeof(bridge_cdr->lastdata)); + ast_copy_string(bridge_cdr->lastapp, S_OR(chan->appl, ""), sizeof(bridge_cdr->lastapp)); + ast_copy_string(bridge_cdr->lastdata, S_OR(chan->data, ""), sizeof(bridge_cdr->lastdata)); } else { /* better yet, in a xfer situation, find out why the chan cdr got zapped (pun unintentional) */ bridge_cdr = ast_cdr_alloc(); /* this should be really, really rare/impossible? */ ast_copy_string(bridge_cdr->channel, chan->name, sizeof(bridge_cdr->channel)); ast_copy_string(bridge_cdr->dstchannel, peer->name, sizeof(bridge_cdr->dstchannel)); ast_copy_string(bridge_cdr->uniqueid, chan->uniqueid, sizeof(bridge_cdr->uniqueid)); - ast_copy_string(bridge_cdr->lastapp, chan->appl, sizeof(bridge_cdr->lastapp)); - ast_copy_string(bridge_cdr->lastdata, chan->data, sizeof(bridge_cdr->lastdata)); + ast_copy_string(bridge_cdr->lastapp, S_OR(chan->appl, ""), sizeof(bridge_cdr->lastapp)); + ast_copy_string(bridge_cdr->lastdata, S_OR(chan->data, ""), sizeof(bridge_cdr->lastdata)); ast_cdr_setcid(bridge_cdr, chan); bridge_cdr->disposition = (chan->_state == AST_STATE_UP) ? AST_CDR_ANSWERED : AST_CDR_NULL; bridge_cdr->amaflags = chan->amaflags ? chan->amaflags : ast_default_amaflags; |