[Home]

Summary:ASTERISK-04190: "delayreject=yes" breaks "trunk=yes"
Reporter:Ryan Courtnage (rcourtna)Labels:
Date Opened:2005-05-16 12:28:09Date Closed:2006-01-19 18:08:58.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) iax_debugs.txt
Description:When trunking 2 * servers via iax2, "trunk=yes" can only be used if "delayreject=no".  

If both trunk and delayreject are set to "yes", trying to dial over the trunk will result in a "Subclass: INVAL" IAX message.



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

The following iax configs for 2 trunked systems will not work.  After removing either "delayreject=yes" _or_ "trunk=yes", they will work:

server 1 iax.conf (imaging):

[general]
bindport = 4569           ; Port to bind to (IAX is 4569)
bindaddr = 0.0.0.0    ; Address to bind to (all addresses on machine)
delayreject=yes                    

[staginguser]
username=imaginguser
type=friend
trunkfreq=20
trunk=yes
secret=4273553
jitterbuffer=no
host=192.168.1.101
context=from-internal


server 2 iax.conf (staging):

[general]
bindport = 4569           ; Port to bind to (IAX is 4569)
bindaddr = 0.0.0.0    ; Address to bind to (all addresses on machine)
delayreject=yes          

[imaginguser]
username=staginguser
type=friend
trunkfreq=20
trunk=yes
secret=4273553
jitterbuffer=no
host=192.168.1.102
context=from-internal  

Comments:By: Clod Patry (junky) 2005-06-09 18:49:14

Is still an issue? No one seems to have any problem, cause you got no reply in ~1 month.
By: maik (maik) 2005-06-12 09:50:32

I have the same problem with CVS HEAD (2005-06-10). The problem seems to be that asterisk sends an ACK first and then an AUTHREQ after receiving a NEW.
By: Michael Jerris (mikej) 2005-06-12 21:14:11

Can somone please test this on head to verify if it is an issue there as well?
By: Joe Antkowiak (antkojm1) 2005-06-17 03:04:41

I just upgraded to head an hour ago and confirmed this is an issue still.
By: Mark Spencer (markster) 2005-06-17 08:53:13

Can you actually attach the trace of the IAX conversation?
By: Joe Antkowiak (antkojm1) 2005-06-18 02:53:27

uploaded.  let me know if you need any other debugs run.
By: Mark Spencer (markster) 2005-06-18 14:16:57

Is this from the called or calling side?  It looks like a great deal of the log is missing.  I note that the call numbers for the "INVAL" call is totally different from the other call.  Again, you mentioned that trunk=yes cannot be used with delayreject=yes, but can you confirm if delayreject=yes works with trunk=no?
By: Joe Antkowiak (antkojm1) 2005-06-20 21:26:07

I've unfortunately had too many issues with this and have to turn off trunking completely, and now all is well.  delayreject=yes works now too.

I thought I had captured more than whats there, I'll grab more from the logs.  what you are seeing is a small portion from the calling side and a small portion from the called side
By: Glenn Stephens (condor) 2005-06-29 19:44:12

I've had the same issue using CVS-HEAD-05/11/05-11:34:47 with very similar configs.

The Sequence from the iax2 debug is:

Server 1 Transmit: NEW
Server 2 Receive: NEW

Server 2 Transmit: ACK
Server 1 Receive: ACK

Server 2 Transmit: AUTHREQ
Server 1 Receive: AUTHREQ

Server 2 Receive: INVAL

- Pause, approx 2 seconds -

Server 1 Transmit: LAGRQ
Server 2 Receive: LAGRQ

Server 1 Receive: INVAL

Call Terminates.

From my playing, it appears that _POSSIBLY_ if there is a failed auth prior to this sequence, then everything will work fine. But I have not had the time to try and replicate this yet.

I have confirmed that setting Server 2 to delayreject=no the call goes through as it should, and I only started seeing this issue after I added trunk=yes to my configs, one added the problem is replicateable 99.99999% of the time.
By: Joe Antkowiak (antkojm1) 2005-07-08 17:16:28

Has anyone looked at this more?
By: Mark Spencer (markster) 2005-07-31 17:35:55

I'd be happy to look at it if someone would actually supply a complete debug.  Not a snippet of debug, not a summary of a debug, but actually attach the iax2 debug for the entirity of the call (with -vvvgc and regular log debug enabled preferably) so that I have somewhere to start from.  Alternatively someone can lab this up where I can login and do some debug.
By: Glenn Stephens (condor) 2005-08-01 01:01:20

Here are the debugs, first the receiver:

Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW
  Timestamp: 00002ms  SCall: 16384  DCall: 00000 [AAA.AAA.AAA.AAA:4569]
  VERSION         : 2
  CALLED NUMBER   : 600
  CODEC_PREFS     : (gsm|ulaw|alaw|g729|g726|adpcm|slin)
  CALLING NUMBER  : XXX
  CALLING PRESNTN : 0
  CALLING TYPEOFN : 0
  CALLING TRANSIT : 0
  CALLING NAME    : Xxxxx Xxxxx
  LANGUAGE        : en
  USERNAME        : xxxxxxxx
  FORMAT          : 4
  CAPABILITY      : 63870
  ADSICPE         : 2
  DATE TIME       : 184643316

Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: ACK
  Timestamp: 00002ms  SCall: 00001  DCall: 16384 [AAA.AAA.AAA.AAA:4569]
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: AUTHREQ
  Timestamp: 00008ms  SCall: 16384  DCall: 16384 [AAA.AAA.AAA.AAA:4569]
  AUTHMETHODS     : 4
  CHALLENGE       : 205945667
  USERNAME        : xxxxxxxx

Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: INVAL
  Timestamp: 00000ms  SCall: 16384  DCall: 16384 [AAA.AAA.AAA.AAA:4569]
Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 000 Type: IAX     Subclass: LAGRQ
  Timestamp: 10003ms  SCall: 16384  DCall: 00001 [AAA.AAA.AAA.AAA:4569]


Now the caller:

   -- Executing Dial("SIP/1XXX-bbfb", "IAX2/xxxxxxxx@xxxxxxxx/600") in new stack
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW
  Timestamp: 00002ms  SCall: 16384  DCall: 00000 [BBB.BBB.BBB.BBB:4569]
  VERSION         : 2
  CALLED NUMBER   : 600
  CODEC_PREFS     : (gsm|ulaw|alaw|g729|g726|adpcm|slin)
  CALLING NUMBER  : XXX
  CALLING PRESNTN : 0
  CALLING TYPEOFN : 0
  CALLING TRANSIT : 0
  CALLING NAME    : Xxxxx Xxxxx
  LANGUAGE        : en
  USERNAME        : xxxxxxxx
  FORMAT          : 4
  CAPABILITY      : 63870
  ADSICPE         : 2
  DATE TIME       : 184643316

   -- Called xxxxxxxx@xxxxxxxx/600
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: ACK
  Timestamp: 00002ms  SCall: 00001  DCall: 16384 [BBB.BBB.BBB.BBB:4569]
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: AUTHREQ
  Timestamp: 00008ms  SCall: 16384  DCall: 16384 [BBB.BBB.BBB.BBB:4569]
  AUTHMETHODS     : 4
  CHALLENGE       : 205945667
  USERNAME        : xxxxxxxx

Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 000 Type: IAX     Subclass: LAGRQ
  Timestamp: 10003ms  SCall: 16384  DCall: 00001 [BBB.BBB.BBB.BBB:4569]
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: INVAL
  Timestamp: 00000ms  SCall: 00001  DCall: 16384 [BBB.BBB.BBB.BBB:4569]
   -- Hungup 'IAX2/xxxxxxxx-16384'
 == No one is available to answer at this time (1:0/0/0)
   -- Executing Congestion("SIP/XXXX-bbfb", "5") in new stack
 == Spawn extension (local, 991600, 2) exited non-zero on 'SIP/XXXX-bbfb'

Changing the delayreject=yes to delayreject=no and issuing an "ixa2 reload" makes the next call go through.
By: Michael Jerris (mikej) 2005-08-01 01:33:06

please attach future debugs as attached .txt files not inline in the bug, thanks.
By: Michael Jerris (mikej) 2005-08-24 01:51:26

debug ready for your review.
By: Olle Johansson (oej) 2005-09-06 11:15:58

Markster: This is waiting for you...

/Housekeeping
By: Olle Johansson (oej) 2005-10-20 02:22:45

Reminder sent to markster.

/Housekeeping
By: Olle Johansson (oej) 2005-12-01 21:35:15.000-0600

MARKSTER!!!!
By: Jan-Peter Koopmann (jkoopmann) 2005-12-19 11:30:53.000-0600

We are seeing the same behaviour here. If you need debug output etc. please let me know.

Markster: Have you had any chance to look at the debug yet?
By: Matt O'Gorman (mogorman) 2006-01-19 18:08:18.000-0600

Committed revision 8320. into 1.2
Committed revision 8323. into trunk

hope this fixes everyones problems ^_^