[Home]

Summary:ASTERISK-03094: Sipgate don't work anymore with newest Asterisk
Reporter:jchaosfm (jchaosfm)Labels:
Date Opened:2004-12-26 15:20:17.000-0600Date Closed:2008-01-15 15:18:50.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) astobj.h.diff
( 1) astobj.h.diff2
( 2) sip_no_peer_debug.txt
( 3) sip_no_peer.txt
( 4) sip.conf-example.txt
( 5) sip.conf-example.txt
( 6) sip.kuj.conf.txt
( 7) sip-debuglog.txt
Description:Asterisk don't work anymore with SIPGATE. Sipgate works fine with asterisk but the newest CVS version don't work with sipgate anymore.
I think the insecure=very is away from the sip compatibility or is it another problem, because this works fine before?

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

More info about this problem http://www.voip-info.org/wiki-Sipgate
Comments:By: jchaosfm (jchaosfm) 2004-12-26 15:22:20.000-0600

The asterisk PBX says: Failed to authenticate user "INCOMING PHONENUMBER" <sip:PHONENUMBER@IP>;tag=as3f7ade
By: Mark Spencer (markster) 2004-12-26 16:04:05.000-0600

The bug guidelines are clearly highlighted in yellow when you place the bug.  You already have a karma of -5 and if you place any more bugs which are not in accordance with those guidelines, they will simply be deleted.

Please read the guidelines before placing any bugs.
By: Mark Spencer (markster) 2004-12-26 17:04:41.000-0600

We encourage people to run CVS head and to report any bugs they find.  We only ask that in the interest of making most efficient use of the time and work of the volunteers that you *read* and *abide* by the bug guidelines which we try to make as clearly visible as possible.

Remember that the bug tracker is serviced by a variety of people who are donating their time to try to help you with your problem and in the process help the project at large.  We expect a certain level of discipline from those who use the system, to properly categorize those bugs in accordance with our recommendations so they can be prioritized properly, and to provide the necessary diagnostics (e.g. a "sip debug" trace and relevant configuration sections of sip.conf since this is a SIP bug) so that we can actually try to determine the cause of the failure.  The bug guidelines were created to facilitate that process so that we make maximum use of your time and ours.

Please provide the output of the "sip debug" and also include the complete sipgate entry from your sip.conf.  Thanks.
By: Olle Johansson (oej) 2004-12-27 07:22:17.000-0600

You are setting nat=yes in the [general] section of sip.conf. The behaviour of nat=yes was changed a few days ago. If you add nat=no in the sipgate entry - will it work better?
By: Mark Spencer (markster) 2004-12-27 07:34:15.000-0600

can you please also show the output of "sip show peer checker"?
By: jchaosfm (jchaosfm) 2004-12-27 07:36:48.000-0600

Nope nat=no don't work

And here are the results of sip show peer checker:

PBX-1*CLI>

 * Name       : checker
 Secret       : <Set>
 MD5Secret    : <Not set>
 Context      : checker
 Language     :
 FromUser     : 9991651
 FromDomain   : sipgate.co.uk
 Callgroup    :  (0)
 Pickupgroup  :  (0)
 Mailbox      :
 LastMsgsSent : -1
 Dynamic      : No
 Callerid     : "" <>
 Expire       : -1
 Expiry       : 900
 Insecure     : Very
 Nat          : No
 ACL          : No
 CanReinvite  : Yes
 PromiscRedir : Yes
 User=Phone   : No
 DTMFmode     : rfc2833
 LastMsg      : 0
 ToHost       : sipgate.co.uk
 Addr->IP     : 217.10.79.219 Port 5060
 Defaddr->IP  : 0.0.0.0 Port 0
 Username     : 9991651
 Codecs       : 0x406 (gsm|ulaw|ilbc)
 Codec Order  : (ilbc|ulaw|gsm)
 Status       : UNKNOWN
 Useragent    :
 Full Contact :
By: Mark Spencer (markster) 2004-12-27 08:11:18.000-0600

Actually, a quick review of the debug suggests this is matching the peer "outfreenumber" and not the "checker" peer.  Do you have a peer called "outfreenumber" which has the same IP address?
By: Olle Johansson (oej) 2004-12-27 08:14:36.000-0600

Additional info: We always match the first peer on IP address. That is the *last* peer in sip.conf with the matching IP address

edited on: 12-27-04 08:15
By: jchaosfm (jchaosfm) 2004-12-27 08:25:53.000-0600

I know that this program is matching the first ip address,

but this is the outfreenumber and haven't the same ip, because it's another service FWD! All my incomming SIP traffice will be blocked on this moment!! It's very strange because i've only UPDATE yesterday Asterisk CVS.


[outfreenumber]
disallow=all
context=outfreenumber
allow=gsm
;allow=ulaw
context=supportdesk
type=peer
secret=XXXXX
username=393534
host=fwd.pulver.com
fromuser=393534
fromdomain=fwd.pulver.com
nat=no
canreinvite=no

edited on: 12-27-04 08:26
By: Olle Johansson (oej) 2004-12-27 08:36:01.000-0600

Any device between Asterisk and SIPgate/FWD?

Outbound proxy, firewall, broadband router with SIP support?
By: Mark Spencer (markster) 2004-12-27 08:41:55.000-0600

It looks like sip_addrcmp was returning the wrong sense (i.e. it should return 0 on match, non-zero otherwise!).

Should be fixed in latest CVS head.  Please confirm it's fixed after giving the mirrors 5 or 10 minutes to catch up.
By: jchaosfm (jchaosfm) 2004-12-27 09:15:41.000-0600

This works better with a few incomming sip numbers!

Sipgate & FWD don't work yet.
I see no message ( Failed to authenticate user "INCOMING PHONENUMBER" <sip:PHONENUMBER@IP>;tag=as3f7ade  ) anymore but the call will be not forwarded to the asterisk PBX but give a BUSY tone with sipgate and with FWD call not found (calling with XLITE to my asterisk PBX)

edited on: 12-27-04 12:30
By: jchaosfm (jchaosfm) 2004-12-28 06:11:49.000-0600

I think there is another bug in the SIP because i can't receive incomming calls from fwd and sipgate. Is there a solution for this problem?
By: joranbrals (joranbrals) 2004-12-28 11:34:12.000-0600

I have the same problem!!!!!!!!!!

SIP DOESN'T WORK WELL NOW!!!
By: Olle Johansson (oej) 2004-12-28 14:55:35.000-0600

In order for us to help you, we really need more information. Please add SIP debug output from failed calls, both of you. Also add configurations.
By: kuj (kuj) 2004-12-28 21:34:44.000-0600

Confirm the inability to find a peer. I have attached a sip debug trace (sip_no_peer.txt) showing that the peer was not found (in this case FWD), even though a "sip show peer fwd" has all the details.

The issue seems to be in the "sip_addrcmp" function. I added a few debug statements to print out every variable used in the various tests inside the function. Clearly, the peerlist/userlist we're trying to match with looks bogus: none of the peers/users have a valid IP address associated with them. Also, the insecure flag is set to "very" for all my "named peers" (not numbered extensions), but doesn't appear to be from the debug output. See sip_no_peer_debug.txt for details.

Both files were generated during a single incoming call from FWD (via the IPKall gateway).

I'll also attach a trimmed down version of my sip.conf (sip.kuj.conf.txt)
By: kuj (kuj) 2004-12-29 15:21:18.000-0600

Seems like the basic assumption in sip_addrcmp is wrong:
 /* We know name is the first field, so we can cast */
 struct sip_peer *p = (struct sip_peer *)name;

If that were true, shouldn't (after this cast) 'name' and 'p->name' be the same? They're not: name really is the peer name, p->name looks to be null.

The net effect is that the search for the peer will fail, sending * into the global default extension context for inbound calls. If the called number is configured there, all is fine. If not, the call is rejected.
By: Olle Johansson (oej) 2004-12-29 15:42:53.000-0600

kuj: Right, there is something really fishy in that part of the objects. If I understand that macro right, we are sending a pointer to the name field and suddenly treats it as a pointer to the peer!
By: kuj (kuj) 2004-12-29 15:52:47.000-0600

oej, which would be fine if "name" indeed were the first field in struct peer. However, with the recent astobj changes, it looks like it is not first anymore. Rather, the "define" of ASTOBJ_COMPONENTS (which sip_peer is) introduces a first field "ast_mutex_t _lock" as per include/asterisk/astobj.h.

I'm trying right now to reverse the order of the things in the definition of ASTOBJ_COMPONENTS. Give me a few ...
By: kuj (kuj) 2004-12-29 16:02:00.000-0600

OK, this looks much better: in astobj.h I changed the define for ASTOBJ_COMPONENTS to switch things around: instead of inserting the mutex _lock as the first field to the struct sip_peer, followed by "name", "refcount" and "objflags" (all in astobj.h), the _lock is added after those fields.

The effect is that the "name" field is the first field of the struct again, and the pointer cast in sip_addrcmp works again.

This is too trivial a fix, once you found it :-) The attached astobj.h.diff has the line reversal in astobj.h
By: kuj (kuj) 2004-12-29 16:11:23.000-0600

And a last change to astobj.h: it contains definitions for ASTOBJ_COMPONENTS and ASTOBJ_COMPONENTS_FULL, both of which "sandwich" the "ast_mutex_t _lock" into the first field position of a struct. Reversing the order for ASTOBJ_COMPONENTS will fix the inbound SIP call problem.

On the off-chance that we do pointer casts for other objects (that use ASTOBJ_COMPONENTS_FULL), the attached astobj.h.diff2 reverses the insertion order for that #define as well.

Don't have a disclaimer submitted, but this is way too trivial for one, I think.
By: Mark Spencer (markster) 2004-12-29 18:17:03.000-0600

Agreed that it's a trivial fix, but kudos to you, kuj, for finding it!  I'd been staring at this for a good 20 minutes, i guess sometimes it just takes a fresh set of eyes!
By: Digium Subversion (svnbot) 2008-01-15 15:18:18.000-0600

Repository: asterisk
Revision: 4560

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r4560 | markster | 2008-01-15 15:18:17 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix inversion error on addrcmp (bug ASTERISK-3094)

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

http://svn.digium.com/view/asterisk?view=rev&revision=4560
By: Digium Subversion (svnbot) 2008-01-15 15:18:50.000-0600

Repository: asterisk
Revision: 4596

U   trunk/include/asterisk/astobj.h

------------------------------------------------------------------------
r4596 | markster | 2008-01-15 15:18:50 -0600 (Tue, 15 Jan 2008) | 2 lines

Make casts work again properly (bug ASTERISK-3094)

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

http://svn.digium.com/view/asterisk?view=rev&revision=4596