[Home]

Summary:ASTERISK-01951: call lost after "Attempting native bridge "
Reporter:tucker (tucker)Labels:
Date Opened:2004-07-05 15:38:40Date Closed:2011-06-07 14:10:13
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) log
Description:incoming call from trusted / authorised X-Lite client is recived, processed and following answer of extension call is lost.
Researched and put on latest cvs update as per suggestion.
Now getting two lines then call crash, more info below

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

Starting asterisk:                                         [  OK  ]
[root@localhost asterisk]# asterisk -r
Asterisk CVS-HEAD-07/05/04-20:31:55, Copyright (C) 1999-2004 Digium.
Written by Mark Spencer <markster@digium.com>
=========================================================================
Connected to Asterisk CVS-HEAD-07/05/04-20:31:55 currently running on localhost (pid = 16532)
Asterisk Ready.
   -- Remote UNIX connection
   -- Saved useragent "Sipura/SPA2000-1.0.33" for peer 2001
   -- Executing Wait("SIP/2001-c06d", "1") in new stack
   -- Executing Dial("SIP/2001-c06d", "SIP/2004|20|tr") in new stack
Jul  5 20:58:19 NOTICE[-298071120]: app_dial.c:689 dial_exec: Unable to create channel of type 'SIP'
 == Everyone is busy/congested at this time
   -- Executing VoiceMail("SIP/2001-c06d", "u2004") in new stack
   -- Playing 'vm-theperson' (language 'en')
   -- Playing 'digits/2' (language 'en')
   -- Playing 'digits/0' (language 'en')
   -- Playing 'digits/0' (language 'en')
 == Spawn extension (sip, 2004, 3) exited non-zero on 'SIP/2001-c06d'
   -- Registered SIP '2004' at 81.101.182.51 port 5060 expires 1800
   -- Saved useragent "X-Lite release 1103m" for peer 2004
   -- Executing Wait("SIP/2004-3715", "1") in new stack
   -- Executing Dial("SIP/2004-3715", "SIP/2001|20|tr") in new stack
   -- Called 2001
   -- SIP/2001-41c6 is ringing
   -- SIP/2001-41c6 answered SIP/2004-3715
   -- Attempting native bridge of SIP/2004-3715 and SIP/2001-41c6
   -- Attempting native bridge of SIP/2004-3715 and SIP/2001-41c6
Jul  5 21:01:54 WARNING[-213800016]: chan_sip.c:674 retrans_pkt: Maximum retries exceeded on call 774A300B-FADA-49A5-A6E9-EB1A79BBFB12@192.168.1.100 for seqno 13324 (Non-critical Response)
Comments:By: Brian West (bkw918) 2004-07-05 19:17:51

let me guess you're behind nat and the phone your calling is behind the same nat?  Or something similar.  And you have canreinvite=yes?

bkw
By: tucker (tucker) 2004-07-06 04:41:59

I am behind a NAT, however the phone calling / being called is on an external network

After reading various items I set canreinvite=no
By: Brian West (bkw918) 2004-07-06 10:07:19

and that fixed it right?
By: tucker (tucker) 2004-07-06 10:16:06

Sasdly not, I already had canreinvite=no when I raised the issue

All I get now is two lines of

   -- Attempting native bridge of SIP/2004-3715 and SIP/2001-41c6
   -- Attempting native bridge of SIP/2004-3715 and SIP/2001-41c6

on the log rather than just one

Any ideas
By: Rob Gagnon (rgagnon) 2004-07-06 11:58:23

is this related to ASTERISK-1951980 ?
By: cshaw59 (cshaw59) 2004-07-06 12:24:16

I'll bet this is related to 1980 and also my report 1959 about the grandstreams. What you posted is not a SIP DEBUG but rather just the verbose output from Asterisk. Can you post a sip debug of your call transaction? I'll bet you'll get a message similar to mine about an error in chan_sip.c around line 1800, Asked to transmit frame of type 64 but we're using type X (X = ID # of your codec).

edited on: 07-06-04 12:12
By: tucker (tucker) 2004-07-06 17:21:26

Nothing left out.. I will do it again with debug on and post tomorrow when other party is available.
I hade seen 0001980..
By: cshaw59 (cshaw59) 2004-07-06 17:37:07

No you didn't leave anything out, it's just not debugging output it's the verbose command output from *. Not getting after you or anything, I'm just curious because that's EXACTLY where mine drops out is after the "Attempting Native Bridge" and then it goes on to give the error about Asking to use a different codec than we're using blah blah... I strongly believe that these are related...

I'm hoping it IS related because the more people experiencing this problem the easier it may become to solve hopefully... :)

edited on: 07-06-04 17:23
By: tucker (tucker) 2004-07-06 17:39:38

I'll do it again tomorrow when the other party is available, he works nights (UK)
Sounds very similar.. Thanks
By: Mark Spencer (markster) 2004-07-07 09:00:34

This would appear to suggest we are not receiving the ACK for our 200 OK.  If you enable sip debug you'll see what is actually going on.
By: tucker (tucker) 2004-07-07 09:07:52

I will do and post info as soon as other party is available after work
By: tucker (tucker) 2004-07-07 15:38:44

I have addeddebug log file
By: mustdie (mustdie) 2004-07-08 00:04:39

I've got the same behavior today. HEAD of 07/05
By: Mark Spencer (markster) 2004-07-08 03:37:24

As I said, according to the debug, we are NOT receiving the ACK to our 200 OK.  

Looking at the messages, I see some mild munging of the "rport" field by Asterisk (we add the rport=5060, but we forget to remove the original rport in the request).  You might try doing "nat=never" to make it ignore rport handling entirely, or alternatively update to this morning's CVS where i've done a stab at fixing it.  If that doesn't fix it, post a new debug and we'll do another spin.
By: tucker (tucker) 2004-07-08 07:55:47

I will get the latest CVS later and retry as suggeted.
I will post update and findings.
Thank you
By: twisted (twisted) 2004-07-13 13:19:44

stephenmtucker - can you post your status at this time?