[Home]

Summary:ASTERISK-10191: Variables set in an IAX2 user/friend no longer make it to the channel created for an (authenticated?) incoming call
Reporter:Steve Davies . (stevedavies)Labels:
Date Opened:2007-08-29 08:04:44Date Closed:2007-08-29 12:54:35
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:
In current SVN trunk, setvars done in a user/friend definition in iax2.conf do not make it to the created channel for an incoming IAX calls.  (Possibly, only for authenticated calls).

I suspect this is a side effect of the changes made in bug http://bugs.digium.com/view.php?id=9315

Here's logs showing the problem (including some extra tracing that I added):

[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27] Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW    
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    Timestamp: 00003ms  SCall: 12056  DCall: 00000 [41.241.31.0:4569]
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    VERSION         : 2
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    CALLING NUMBER  : 0878202303
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    CALLING NAME    : Steve Davies
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    FORMAT          : 1024
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    CAPABILITY      : 2
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    USERNAME        : 0878202303
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    CALLED NUMBER   : 0216575160
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    DNID            : 0216575160
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: New max nontrunk callno is 11
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: Creating new call structure 10
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: Received packet 0, (6, 1)
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: IAX subclass 1 received
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: For call=10, set last=3
[Aug 29 14:54:27] VERBOSE[5972] chan_iax2.c: Best match was 0878202303 with score 0
[Aug 29 14:54:27] VERBOSE[5972] chan_iax2.c: Using user 0878202303
[Aug 29 14:54:27] VERBOSE[5972] chan_iax2.c: Setting FROM-PEER=0878202303 on call 10
[Aug 29 14:54:27] VERBOSE[5972] chan_iax2.c: Setting ACCOUNTCODE=ctel on call 10
[Aug 29 14:54:27] VERBOSE[5972] chan_iax2.c: Setting accountcode = ctel
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: Sending 14 on 10/12056 to 41.241.31.0:4569
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27] Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: AUTHREQ
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    Timestamp: 00014ms  SCall: 00010  DCall: 12056 [41.241.31.0:4569]
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    AUTHMETHODS     : 2
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    CHALLENGE       : -12424811
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    USERNAME        : 0878202303
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27] Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: AUTHREP
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    Timestamp: 00024ms  SCall: 12056  DCall: 00010 [41.241.31.0:4569]
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]    MD5 RESULT      : 17972f6d3ce514fed01c61c28134ef22
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: Received packet 1, (6, 9)
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: Cancelling transmission of packet 0
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: IAX subclass 9 received
[Aug 29 14:54:27] DEBUG[5972] chan_iax2.c: For call=10, set last=24
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]     -- Accepting AUTHENTICATED call from 41.241.31.0:
      > requested format = ilbc,
      > requested prefs = (),
      > actual format = gsm,
      > host prefs = (g729|ilbc|gsm|speex|alaw|ulaw),
      > priority = mine
[Aug 29 14:54:27] DEBUG[5972] pbx.c: Launching 'NoOp'
[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]     -- Executing [0216575160@from-cust-ctel:1] NoOp("IAX2/0878202303-10", "accountcode= FROM-PEER=") in new stack


Here you can see that the variables get copies from the user structure into the iax2 structure (ie iaxs[callno]):

[Aug 29 14:54:27] VERBOSE[5972] chan_iax2.c: Setting FROM-PEER=0878202303 on call 10
[Aug 29 14:54:27] VERBOSE[5972] chan_iax2.c: Setting ACCOUNTCODE=ctel on call 10

And that the accountcode in the iax2 structure is set too:

[Aug 29 14:54:27] VERBOSE[5972] chan_iax2.c: Setting accountcode = ctel

But by the time we get into the dialplan they are not there:

[Aug 29 14:54:27] VERBOSE[5972] logger.c: [Aug 29 14:54:27]     -- Executing [0216575160@from-cust-ctel:1] NoOp("IAX2/0878202303-10", "accountcode= FROM-PEER=") in new stack



****** ADDITIONAL INFORMATION ******

This regression occurred somewhere between SVN rev 74812 and 80000 or so.
Comments:By: Steve Davies . (stevedavies) 2007-08-29 08:57:09

Looks like the variables have ended up with the IAX "remote" variables accessed via the IAXVAR function.

I'm not sure if this is intentional or not, but here are the problems:

1) This is very much not backwards compatible!

2) IAXVAR function is documented to set or retrieve a _remote_ variable.  which these specifically are not.  I don't want a variable sent by a peer to be able to overwrite viariables I set myself.  especially when I'm using that variable to know which peer it is for billing!

3) You can no longer treat SIP and IAX channels the same.  Setvars for SIP are in ordinary channel variables, ones set in IAX channels are found via IAXVAR function.
By: Steve Davies . (stevedavies) 2007-08-29 09:09:57

The issue is that ast_iax2_new now puts all the variables in the private structure into a variablestore.   The code used to just set channel variables.

In respect of variables that came from the remote peer, that's a good thing because they should be kept distinct for security reasons.

But there is a flawed assumption that all of those variables came from the remote system.

That assumption is incorrect because of the variables that came from setvar in the user/friend entry, which are in the same linked list.

Steve
By: Steve Davies . (stevedavies) 2007-08-29 09:51:56

Here's a recipe for reproducing the problem:

iax.conf:

[user]
type=friend
host=dynamic
auth=md5
secret=user
username=me
context=user-context
accountcode=user
setvar=ACCOUNTCODE=user
setvar=FROM-PEER=user

extensions.conf:

[user-context]
exten => _X.,1,Noop(channel variable FROM-PEER = ${FROM-PEER} - iaxvar FROM-PEER = ${IAXVAR(FROM-PEER})
exten => _X.,n,Hangup

Try that with a pre-75805 svn trunk, and a post-75805 one.  You'll see that the setvar variables have disappeared from the channel variables and moved to be with any received from the remote box in the store.

This creates a backward compatibility issue, a compatibility issue with sip channels etc.
By: Digium Subversion (svnbot) 2007-08-29 10:02:59

Repository: asterisk
Revision: 81335

------------------------------------------------------------------------
r81335 | tilghman | 2007-08-29 10:02:59 -0500 (Wed, 29 Aug 2007) | 2 lines

Changed one too many variable settings in issue ASTERISK-9044 (closes issue ASTERISK-10191)

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-08-29 12:54:35

Repository: asterisk
Revision: 81352

------------------------------------------------------------------------
r81352 | murf | 2007-08-29 12:54:32 -0500 (Wed, 29 Aug 2007) | 128 lines

Merged revisions 81326,81332-81335,81341,81343-81345,81347-81348,81350 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r81326 | file | 2007-08-28 20:21:08 -0600 (Tue, 28 Aug 2007) | 2 lines

Add inline function for signed linear subtraction.

................
r81332 | file | 2007-08-29 08:16:07 -0600 (Wed, 29 Aug 2007) | 12 lines

Merged revisions 81331 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r81331 | file | 2007-08-29 11:13:55 -0300 (Wed, 29 Aug 2007) | 4 lines

(closes issue ASTERISK-9405)
Reported by: mattv
Make rtp timeouts work even if two RTP streams are directly bridged in the RTP stack.

........

................
r81333 | mmichelson | 2007-08-29 08:19:33 -0600 (Wed, 29 Aug 2007) | 5 lines

Changing a NOTICE to a DEBUG.

(closes issue ASTERISK-10190, reported and patched by junky, with small modification by me)


................
r81334 | file | 2007-08-29 09:19:11 -0600 (Wed, 29 Aug 2007) | 2 lines

Add API calls for iterating through an event. This should allow events to have multiple information elements (while there was nothing preventing it before you could not actually access any except the first one).

................
r81335 | tilghman | 2007-08-29 09:21:10 -0600 (Wed, 29 Aug 2007) | 2 lines

Changed one too many variable settings in issue ASTERISK-9044 (closes issue ASTERISK-10191)

................
r81341 | mmichelson | 2007-08-29 09:57:27 -0600 (Wed, 29 Aug 2007) | 16 lines

Merged revisions 81340 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r81340 | mmichelson | 2007-08-29 10:52:42 -0500 (Wed, 29 Aug 2007) | 8 lines

This fix creates a more accurate way of detecting whether realtime members were deleted.
(closes issue 10541, reported by Alric, patched by me)

The REALLY nice things about this patch is that queue members now have a "realtime" field
which will be true if the member is a realtime member. This means we can check this value
prior to certain processing if it should ONLY be done for realtime members.


........

................
r81343 | russell | 2007-08-29 09:59:10 -0600 (Wed, 29 Aug 2007) | 11 lines

Merged revisions 81342 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r81342 | russell | 2007-08-29 10:57:29 -0500 (Wed, 29 Aug 2007) | 3 lines

If chan_h323 is not being built, don't use g++ to do the final link of Asterisk.
(in response to a question on the asterisk-dev list)

........

................
r81344 | file | 2007-08-29 10:03:51 -0600 (Wed, 29 Aug 2007) | 2 lines

To keep others happy... revert part of my additions so trunk works.

................
r81345 | file | 2007-08-29 10:07:35 -0600 (Wed, 29 Aug 2007) | 2 lines

This concludes bringing trunk back to a working state.

................
r81347 | mmichelson | 2007-08-29 10:09:02 -0600 (Wed, 29 Aug 2007) | 11 lines

Merged revisions 81346 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r81346 | mmichelson | 2007-08-29 11:08:09 -0500 (Wed, 29 Aug 2007) | 3 lines

Changed some tabs to spaces


........

................
r81348 | file | 2007-08-29 10:25:30 -0600 (Wed, 29 Aug 2007) | 2 lines

Return ast_event_get_ie_raw to using an iterator and fix logic in ast_event_iterator_next.

................
r81350 | mmichelson | 2007-08-29 10:39:40 -0600 (Wed, 29 Aug 2007) | 20 lines

Merged revisions 81349 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r81349 | mmichelson | 2007-08-29 11:35:29 -0500 (Wed, 29 Aug 2007) | 12 lines

This patch, in essence, will correctly pause a realtime queue member and reflect those
changes in the realtime engine.

(issue ASTERISK-10060, reported by irroot, patch by me)

This patch creates a new function called update_realtime_member_field, which is a generic
function which will allow any one field of a realtime queue member to be updated. This patch
only uses this function to update the paused status of a queue member, but it lays the foundation
for persisting the state of a realtime member the same way that static members' state is maintained
when using the persistentmembers setting


........

................

------------------------------------------------------------------------