[asterisk-bugs] [Asterisk 0019202]: [patch] switching From-address mid-register breaks channel variables
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri May 6 15:01:18 CDT 2011
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=19202
======================================================================
Reported By: wdoekes
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 19202
Category: Channels/chan_sip/General
Reproducibility: always
Severity: minor
Priority: normal
Status: ready for review
Asterisk Version: 1.4.41
JIRA: SWP-3397
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2011-04-29 05:12 CDT
Last Modified: 2011-05-06 15:01 CDT
======================================================================
Summary: [patch] switching From-address mid-register breaks
channel variables
Description:
Hi,
I'm using a inbound proxy before my asterisk which guesses which account
someone is using based on message headers and IP addresses. This is not
reliable until I get a Digest username. When I get the digest username I
am certain which user it is, and I replace the From-address accordingly.
In this scenario, the following can happen:
(1) INVITE from CLIENT to PROXY
(2) PROXY replaces From: with "Joe" and sends to ASTERISK
(3) ASTERISK challenges the INVITE with a 40[17]
(4) INVITE from CLIENT TO PROXY using Digest username "Lucy"
(5) PROXY replaces From: with "Lucy" and sends to ASTERISK
(6) ASTERISK handles INVITE fine...
... except for the fact that the channel variables are now duplicated
(and in the wrong order).
sip.conf:
[JoeUser]
setvar=username=Joe
accountcode=JoeAccount
...
[LucyUser]
setvar=username=Lucy
accountcode=LucyAccount
...
Now, in my dialplan:
- ${CDR(accountcode)} equals "LucyAccount"
and
- ${username} equals "Joe"
Why is that? Because the channel variables set during the first INVITE
are not destroyed. And, due to the linked-list nature of chanvars, they
are in the "wrong" order, containing first username=Lucy and then
username=Joe.
When copying the chanvars to the dialplan context using
pbx_builtin_setvar_helper Joe overwrites Lucy, hence the inconsistency.
The attached patch should fix it.
Regards,
Walter Doekes
OSSO B.V.
P.S. I'm expecting someone to reply that switching From: mid-INVITE is
not legal, SIP-wise. As a pre-emptive response to that:
(1) I couldn't find the relevant RFC-part that states so and,
(2) asterisk is inconsistent in it's behaviour because it *does* accept
the switch, apart from this bug.
======================================================================
----------------------------------------------------------------------
(0134597) svnbot (reporter) - 2011-05-06 15:01
https://issues.asterisk.org/view.php?id=19202#c134597
----------------------------------------------------------------------
Repository: asterisk
Revision: 317867
U branches/1.8/channels/chan_sip.c
------------------------------------------------------------------------
r317867 | russell | 2011-05-06 15:01:17 -0500 (Fri, 06 May 2011) | 10
lines
chan_sip: Destroy variables on a sip_pvt before copying vars from the
sip_peer.
Don't duplicate variables on the sip_pvt. Just reset the variable list
each
time.
(closes issue https://issues.asterisk.org/view.php?id=19202)
Reported by: wdoekes
Patches:
issue19202_destroy_challenged_invite_chanvars.patch uploaded by
wdoekes (license 717)
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=317867
Issue History
Date Modified Username Field Change
======================================================================
2011-05-06 15:01 svnbot Checkin
2011-05-06 15:01 svnbot Note Added: 0134597
======================================================================
More information about the asterisk-bugs
mailing list