[Home]

Summary:ASTERISK-11892: asterisk locks after p2p sip channel bridge
Reporter:pj (pj)Labels:
Date Opened:2008-04-22 13:22:01Date Closed:2011-06-07 14:03:07
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) lock.txt
( 1) show-lock.txt
Description:simple call between two sip phones (both have same codec),
console log and 'core show locks' attached
this bug was probably caused after huge commits in rev 114190,
it happens in 100% of sip calls, when p2p bridge is attempted,
so it's really big issue!
Comments:By: pj (pj) 2008-04-22 13:33:19

forgot to tell, that this debug is from call between tls and udp peer, but simillar lock happened with simple two sip udp peers,
call is almost immediatelly dropped,
I'm not uploading another debug, because it's easy reproductible.


By: pj (pj) 2008-04-22 13:42:20

another issue, really related to commit r114190 is, that 'sip show peers' displays peers in random/unsorted order.
By: Steve Murphy (murf) 2008-04-23 10:09:33

pj--

I have a simple two-sip-phone setup here, and it works great on trunk.
So, you're going to have to help me...

First of all, using "make menuselect", for compiler options, set DEBUG_THREADS and recompile. When the call is made, and things lock up, enter the "core show locks" command and let's see what you get.

As to "sip show peers", what order were the peers in before? It wouldn't be too hard (I think) to push them out in alphabetical order based on name.... would that be OK?

By: pj (pj) 2008-04-23 10:16:52

murf, it was compiled with this options:
cat ~/.asterisk.makeopts
MENUSELECT_CFLAGS=DONT_OPTIMIZE DEBUG_THREADS LOADABLE_MODULES DEBUG_CHANNEL_LOCKS

"core show locks" is part of attached lock.txt

"sip show peers" output, before your huge commit, displayed peers in order in what peers was defined in sip.conf (in reverse order)
I will try fresh trunk again, late today, and will report back if something changed.


By: Steve Murphy (murf) 2008-04-23 10:21:45

OOpps. sorry, too early in the morning. Yes, you do have "core show lock" info, which is pretty useless, just points to a contention from inside the ao2 stuff.

I need to reproduce this to proceed. Give me more info on the setup. As in the sip.conf stuff for the two phones involved; what make & model of phone, the dialplan entries for those extens, etc. Anything you think might help me.
By: Steve Murphy (murf) 2008-04-23 10:25:38

As to the order of the peers (or users, or dialogs), it was forever lost when we moved away from linked lists in chan_sip. I can store and sort the entries before printing them, however, and the most reasonable is to sort in alpha order on the peer/user/dialog name... is this ok?
By: pj (pj) 2008-04-23 10:37:56

yes, alphabetically sorted peer output will be fine (no matter of order in sip.conf)
one thing, that can be specific is, that I'm dialing two phones, both was ringing, answered was sip device.
Dial(SIP/${EXTEN}&Skinny/${EXTEN}@PJ);

phones was defined with this simple sip.conf template:
[phone](!)
type=peer
host=dynamic
qualify=4000
qualifyfreq=20
nat=yes
canreinvite=no
disallow=all
allow=g729,gsm,ilbc
callcounter=yes
busylevel=1
allowsubscribe=yes
subscribecontext=linestates
context=zamestnanci


I will post some debugs later today.
By: pj (pj) 2008-04-23 14:10:50

another weird behaviour:
even when peer is successfully registered, calls placed from this phone are not placed from peer context, but are placed from context specified in [general] section in sip.conf (here I have from-guest context)

ipbx*CLI> sip show peer 324p

 Addr->IP     : 193.85.164.154 Port 11676
 Defaddr->IP  : 0.0.0.0 Port 5060
 Transport    : UDP
 Def. Username:
 SIP Options  : (none)
 Codecs       : 0x502 (gsm|g729|ilbc)
 Codec Order  : (g729:20,gsm:20,ilbc:30)
 Auto-Framing :  No
 100 on REG   : No
 Status       : OK (371 ms)
 Useragent    : RTC/1.5.5374
 Reg. Contact : sip:10.0.0.3:12654



[Apr 23 21:13:26]   == Using SIP RTP CoS mark 5
[Apr 23 21:13:26] Sending to 193.85.164.154 : 11676 (NAT)
[Apr 23 21:13:26] Using INVITE request as basis request - 0fa50eb50000000000f0172176a5c801
[Apr 23 21:13:26] No user '324p' in SIP users list
[Apr 23 21:13:26] No matching peer for '324p' from '193.85.164.154:11676'
[Apr 23 21:13:26] Found RTP audio format 8
[Apr 23 21:13:26] Found RTP audio format 0
[Apr 23 21:13:26] Found RTP audio format 3
[Apr 23 21:13:26] Found RTP audio format 97
[Apr 23 21:13:26] Found RTP audio format 101
[Apr 23 21:13:26] Peer audio RTP is at port 193.85.164.154:11698
[Apr 23 21:13:26] Found audio description format GSM for ID 3
[Apr 23 21:13:26] Found audio description format PCMA for ID 8
[Apr 23 21:13:26] Found audio description format PCMU for ID 0
[Apr 23 21:13:26] Found unknown media description format RED for ID 97
[Apr 23 21:13:26] Found audio description format telephone-event for ID 101
[Apr 23 21:13:26] Capabilities: us - 0x50a (gsm|alaw|g729|ilbc), peer - audio=0xe (gsm|ulaw|alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0xa (gsm|alaw)
[Apr 23 21:13:26] Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
[Apr 23 21:13:26] Peer audio RTP is at port 193.85.164.154:11698
[Apr 23 21:13:26] Looking for 959 in from-guest (domain ipbx.i.cz)
[Apr 23 21:13:26] list_route: hop: <sip:10.0.0.3:12654>
[Apr 23 21:13:26]
<--- Transmitting (NAT) to 193.85.164.154:11676 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.0.3:12654;branch=z9hG4bKadd9b7fc89-0;received=193.85.164.154
From: "HTC_TyTN" <sip:324p@ipbx.i.cz>;tag=94e3dfc76b;epid=9b9e52b330
To: <sip:959@ipbx.i.cz>
Call-ID: 0fa50eb50000000000f0172176a5c801
CSeq: 1 INVITE
Server: Asterisk PBX SVN-trunk-r114595
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:959@193.179.38.20>
Content-Length: 0


<------------>
[Apr 23 21:13:26]     -- Executing [959@from-guest:1] Set("SIP/ipbx.i.cz-082a5e58", "CALLERID(name)=HTC_TyTN (nreg)") in new stack
By: pj (pj) 2008-04-23 14:20:56

uploading another show-lock.txt, but probably not showing more than first,
it happed in this situation:
call from valid, registered peer named '324',
call is placed from 'from-guest' context, not peer defined context!
call is answered on another registerd sip peer named '324p'
By: pj (pj) 2008-04-23 14:29:36

keep in mind, that I have peers defined as 'type=peer' not 'type=friend'
By: pj (pj) 2008-04-24 11:29:38

murf, do you have sufficient information to investigate this issue or waiting for some more debugs from me? I found issue with very similar symptoms, as I have, in bugreport 0012514 it's probably related (this issue was 'resolved', but I think simply moving this messages into debug level doesn't really solve this issue).


By: Steve Murphy (murf) 2008-06-17 16:11:57

pj-- I fulfilled your request in trunk for sorted peers & users with the
'sip show peers' and 'sip show users' cli commands. see rev 123448 in trunk.

I'm going to try again to see if I can repro your results. I'm learning
what you can & can't do to get the

   -- Packet2Packet bridging SIP/snom360-082af6d8 and SIP/polycom430-082b5d40

As I started out, I could not reproduce your lockup in trunk.
But, given your config file template, I began to introduce things you
had in your entries one by one into mine. I called two sip phones instead of
one. No diff. Nat=yes vs Nat = no, no diff. disallow/allow differences made
the same. No diff. I hit the jackpot (maybe) when I specified the
qualify and qualifyreq lines... now, then things got all locked up royal,
and the stack corrupted, and all sort of nasty things. More to come.
By: Steve Murphy (murf) 2008-06-19 13:15:34

And now, today, and all day yesterday, I am completely unable to
recreate any of the problems I had previously!

So, before I keep pounding my head against the wall,
can you verify that this is still a problem, pj? I've
wasted a bit of time on it, and if it's not a problem
any more, I can rest easy.
By: pj (pj) 2008-06-19 16:48:43

I will try a fresh trunk soon and report result back,
I was not updating a months, because of no activity in this bugreport, so maybe it's really fixed yet.
By: pj (pj) 2008-06-24 06:08:45

I tried fresh trunk r124539, it doesn't crash anymore,
but issue with peer not matching peer definition in sip.conf (as I wrote in this bugreport msg id #85907) still persist. Peer is successfully registered and qualified OK, but when peer try to dial, asterisk doesn't match peer entry as defined in sip.conf. As consequence, call is placed from context defined in [general] instead of peer context and also other options from peer's entry is not used/rewrited (like caller id). I'm using xlite softphone, same issue has my colegue, with twinkle softphone.
If you need another/detailed debug, please let me know.

[Jun 24 09:42:32] Using INVITE request as basis request - YzA4MmRkYTAxYmI2Mjc4MmYwYjZlNDQ5NGRiODA4MWI.
[Jun 24 09:42:32] No user '324' in SIP users list
[Jun 24 09:42:32] No matching peer for '324' from '193.85.164.154:10838'
By: pj (pj) 2008-06-27 14:09:05

can't be my issue with failed peer matching related to option, that I use in sip.conf?
match_auth_username=yes
By: pj (pj) 2008-07-20 07:02:55

I upgraded to latest svn trunk r132312, and it seems, that issue with peer not matching is gone away (and also locking issue is gone). It can be closed, thanks.
By: Steve Murphy (murf) 2008-07-20 14:06:54

User reports problem solved by changes coincidentally made.

(I love it when this happens).