[Home]

Summary:ASTERISK-12420: Sip to Sip dial and rtsavesysname not working in latestsvn
Reporter:Kamil Czajko (kactus)Labels:
Date Opened:2008-07-21 08:08:13Date Closed:2009-01-28 17:03:43.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hello everyone

Have been playing with SVN-trunk-r132312M, looks like it has fixed alot of the issues I experienced before, but I have come across two problems.

Firstly dialing a realtime sip (no rtcache) such as Account1 dialing Account2 produces the output:


   -- Executing Dial("SIP/Account1-0880b814", "SIP/Account2")
[Jul 21 20:33:08] WARNING[46712]: app_dial.c:1476 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Executing Dial("SIP/Account1-0880b814", "SIP/Account2")
[Jul 21 20:33:08] WARNING[46712]: app_dial.c:1476 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Executing Dial("SIP/Account1-0880b814", "SIP/Account2")
[Jul 21 20:33:08] WARNING[46712]: app_dial.c:1476 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Auto fallthrough, channel 'SIP/Account1-0880b814' status is 'CHANUNAVAIL'
   -- Executing Hangup("SIP/Account1-0880b814", "")

The same box, with the same configs running 1.4.17 produces this:

   -- Executing Dial("SIP/Account1-3", "SIP/Account2")
   -- Called Account2
   -- SIP/Account2-087b0000 is ringing

Quite a bit of a problem especially when inbound call termination occurs on another box and is dialed at your box as an extension. I experienced the exact same behaviour when an IAX peer was dialing a sip extension (ie exten => NUM,1,Dial(IAX2/Account:Pass@box2/accounttodial)) it worked in previous betas of 1.6 as well.

Secondly sip peers that registered successfully in the SVN did not update the regserver field in the sip table while they did under 1.4.17 (and betas of 1.6)

Please let me know if you need any more info.

All the best - Kamil

Comments:By: Kamil Czajko (kactus) 2008-07-24 21:03:41

Please note that both these issues do not occur in SVN-branch-1.6.0-r133524

Regserver works correctly, and can dial sips directly.

Thank you
By: Leif Madsen (lmadsen) 2008-12-05 09:24:04.000-0600

Do you have the ability to test this and see if this is still an issue?
By: Leif Madsen (lmadsen) 2009-01-05 16:10:46.000-0600

(I was originally going to close this issue because I thought it was the reporters setup, but after looking more closely and spending some time in the code, I've confirmed this is really an issue, more specifically with either the call to ast_update_realtime in chan_sip.c, or ast_update_realtime itself)

It seems part of this bug is certainly an issue. I was not getting this to work correctly in trunk, and found out why:  you need to update your table to use 'defaultname' and not 'username'. While this should still work as there is code that appears to check for the existence of 'username', it doesn't appear to work quite right.

The code in chan_sip.c is this:

ast_update_realtime(tablename, "name", peername, "ipaddr", ipaddr,"port", port, "regseconds", regseconds,"useragent", useragent,deprecated_username ? "username" : "defaultuser", defaultuser,syslabel, sysname, SENTINEL); /* note syslabel _can_ be NULL */

But the command that gets executed is this:

UPDATE sipfriends SET ipaddr='192.168.128.129', port='13486', regseconds='1231178086', regserver='X-Lite release 1014k stamp 47051' WHERE name='105'

It made no sense to me really that once I updated to username from defaultuser in the database that information would actually get into the database. So after doing that, I got the output again after changing it back to 'username', and this is what I get (which makes sense as to why it wasn't working before):

UPDATE sipfriends SET ipaddr='192.168.128.129', port='42334', regseconds='1231178434', username='X-Lite release 1014k stamp 47051', regserver='105' WHERE name='my_system_name'

That fails, and thus the record is not updated in the DB.

So something funky is going on either with the call to ast_update_realtime from chan_sip.c, or the ast_update_realtime() function is wonky.
By: Leif Madsen (lmadsen) 2009-01-05 16:11:19.000-0600

Assigning to mnicholson because I believe this is an issue he'll be able to solve.
By: Matthew Nicholson (mnicholson) 2009-01-07 17:45:31.000-0600

blitzrage,

Is it possible for me to access your test environment?
By: Leif Madsen (lmadsen) 2009-01-12 11:38:10.000-0600

It is.. still need access to it?
By: Kamil Czajko (kactus) 2009-01-27 20:22:51.000-0600

Hello Everyone

Sorry I was away over Dec. I am building a test enviornment now and will post results later today.

Thank you.
By: Kamil Czajko (kactus) 2009-01-27 22:22:40.000-0600

Hi Again,

Seems I've hit a different issue 14351 for the time being will try again once that is resolved.
By: Leif Madsen (lmadsen) 2009-01-28 17:03:42.000-0600

I'm quite confident this issue is now resolved now that 14205 has been committed. I was testing both the issues brought up here and in 14205, and I'm pretty sure they come from the same problem.

This is now fixed, and I'm closing this issue. Please find a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to have this reopened should you still feel this is an issue. Thanks!