Calls from one specific phone dropped

Stinger81

Joined
Oct 30, 2008
Messages
56
Likes
0
Points
0
#1
Okay, I got me a strange one today. One of my collegues, who works from home, tries to call the office with his cell phone. When our box "answers" the call, it is being hung up. He put his sim card in another phone, still causing the hangup. Is he using his landline, he doesn't get hung up, so it also can't be his hands radiating some magical kind of energy causing the hangup.

It doesn't matter which inbound route is followed, on all he will get hung up with his cell phone.
Other cell phones don't get hung up.
Calling him on his cell phone, from inside, can also be done without any problem.
I tried enabling and disabling "Send RINGING", to no effect.


I'm out of ideas, anyone else got some inspiration?
Here's part of the log where it seems to go wrong. My phone rings about half a ring and then displays missed call.
Dec 1 11:58:25 VERBOSE [23489] logger.c: -- Executing [s@macro-dial:7] Dial("SIP/patton1-b7c03968", "SIP/1351||tTrwW") in new stack
Dec 1 11:58:25 WARNING [23489] rtp.c: Unable to set TOS to 184
Dec 1 11:58:25 VERBOSE [23489] logger.c: -- Called 1351
Dec 1 11:58:25 VERBOSE [23489] logger.c: -- SIP/1351-08e9fbf8 is ringing
Dec 1 11:58:25 VERBOSE [23489] logger.c: -- SIP/1351-08e9fbf8 is ringing
Dec 1 11:58:25 VERBOSE [23489] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on 'SIP/patton1-b7c03968' in macro 'dial'
Dec 1 11:58:25 VERBOSE [23489] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on 'SIP/patton1-b7c03968' in macro 'exten-vm'
Dec 1 11:58:25 VERBOSE [23489] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on 'SIP/patton1-b7c03968'
Dec 1 11:58:25 VERBOSE [23489] logger.c: -- Executing [h@macro-dial:1] Macro("SIP/patton1-b7c03968", "hangupcall") in new stack
Dec 1 11:58:25 VERBOSE [23489] logger.c: -- Executing [s@macro-hangupcall:1] GotoIf("SIP/patton1-b7c03968", "1?skiprg") in new stack
Dec 1 11:58:25 VERBOSE [23489] logger.c: -- Goto (macro-hangupcall,s,4)
 

Bob

Joined
Nov 4, 2007
Messages
2,400
Likes
1
Points
36
#2
Stinger81,

Need some more info to assist.

Incoming lines : SIP/IAX/ZAP
Interface if Zap: TDM400 / A400 / E1 / T1

The issue is most likely not to do with your phone which is the information that you published.

Regards

Bob
 

wiseoldowl

Joined
Aug 19, 2008
Messages
251
Likes
0
Points
0
#3
Stinger81 said:
Dec 1 11:58:25 VERBOSE [23489] logger.c: -- Executing [s@macro-dial:7] Dial("SIP/patton1-b7c03968", "SIP/1351||tTrwW") in new stack
I'm looking suspiciously at that s@macro-dial:7 - when a call completes normally, does it also start with the s@ pattern? The reason I ask is because just looking at this, I'm thinking that there's no DID number to match to any of your incoming routes. In that case I would normally send you here for more information:
http://www.freepbx.org/support/document ... nd-it-and-

BUT what would be really weird is if it's the same incoming trunk and landline calls and most cell phone calls complete normally, but one specific cell provider has somehow figured out that you can accept SIP calls and is trying to send them to you directly, bypassing the PSTN. Normally that could only happen if you have registered your trunk number(s) with one of the ENUM registries (or an upstream provider has done that on your behalf). That would certainly cause the issue you're having - the call would be coming to you directly without a DID that you recognize. What happens if you allow anonymous SIP calls (on the General settings page), does that make any difference?
 

Stinger81

Joined
Oct 30, 2008
Messages
56
Likes
0
Points
0
#4
Okay, I guess I should have told you a bit more about our situation.

Our external lines are four ISDN2 lines, using a block of 20 DID's
These ISDN2 lines come into a Patton 4638, which translates them to SIP and sends them to our box.

In our box, we have defined several inbound routes, including an "Any CID/Any DID".
I defined a route for one of the unused DID's, pointing directly to my extension for testing in this situation, but with any and every DID this problem arises.

No matter which DID he calls, he is getting put through the right path. I can verify that by the announcements it is going through, or by the fact that if he dials the DID patched through to my extension, my extension rings. So the DID's are recognized, that's not the/an issue.

Next, his cell phone provider... That would be the Dutch KPN. The same one that provides us our ISDN2 lines.
I happen to use KPN too for my cell phone, and I don't have any problem at all calling in.
So that kind of eliminates the possibility of the provider causing this, I would guess...

Hope this is enough info to keep the thinking going. ;)
 

Stinger81

Joined
Oct 30, 2008
Messages
56
Likes
0
Points
0
#5
It's getting even stranger... Somehow, the issue is resolved, without me changing anything...

Anyway, all who responded: Thanks for your help!!!
 

Stinger81

Joined
Oct 30, 2008
Messages
56
Likes
0
Points
0
#6
Guess what... The critter is back...
Short: call from that specific cell phone dropped on answer.

Here's an extraction from the logs where it enters an announcement:
log said:
Dec 3 11:57:45 WARNING [23398] rtp.c: Unable to set TOS to 184
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:1] Set("SIP/patton1-08f99ca8", "__FROM_DID=111111111") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:2] Gosub("SIP/patton1-08f99ca8", "app-blacklist-check|s|1") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [s@app-blacklist-check:1] LookupBlacklist("SIP/patton1-08f99ca8", "") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [s@app-blacklist-check:2] GotoIf("SIP/patton1-08f99ca8", "0?blacklisted") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [s@app-blacklist-check:3] Return("SIP/patton1-08f99ca8", "") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:3] GotoIf("SIP/patton1-08f99ca8", "0 ?cidok") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:4] Set("SIP/patton1-08f99ca8", "CALLERID(name)=222222222") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:5] NoOp("SIP/patton1-08f99ca8", "CallerID is "222222222" <222222222>") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:6] Set("SIP/patton1-08f99ca8", "__CALLINGPRES_SV=allowed_not_screened") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:7] SetCallerPres("SIP/patton1-08f99ca8", "allowed_not_screened") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:8] Set("SIP/patton1-08f99ca8", "_RGPREFIX=2XP: ") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:9] Set("SIP/patton1-08f99ca8", "CALLERID(name)=2XP: 222222222") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [111111111@from-pstn:10] Goto("SIP/patton1-08f99ca8", "app-announcement-4|s|1") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Goto (app-announcement-4,s,1)
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [s@app-announcement-4:1] GotoIf("SIP/patton1-08f99ca8", "0?begin") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [s@app-announcement-4:2] Answer("SIP/patton1-08f99ca8", "") in new stack
Dec 3 11:57:45 VERBOSE [3605] logger.c: -- Executing [s@app-announcement-4:3] Wait("SIP/patton1-08f99ca8", "1") in new stack
Dec 3 11:57:46 VERBOSE [3605] logger.c: == Spawn extension (app-announcement-4, s, 3) exited non-zero on 'SIP/patton1-08f99ca8'
Dec 3 11:58:01 WARNING [23398] rtp.c: Unable to set TOS to 184
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:1] Set("SIP/patton1-08eca338", "__FROM_DID=111111111") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:2] Gosub("SIP/patton1-08eca338", "app-blacklist-check|s|1") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [s@app-blacklist-check:1] LookupBlacklist("SIP/patton1-08eca338", "") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [s@app-blacklist-check:2] GotoIf("SIP/patton1-08eca338", "0?blacklisted") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [s@app-blacklist-check:3] Return("SIP/patton1-08eca338", "") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:3] GotoIf("SIP/patton1-08eca338", "0 ?cidok") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:4] Set("SIP/patton1-08eca338", "CALLERID(name)=222222222") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:5] NoOp("SIP/patton1-08eca338", "CallerID is "222222222" <222222222>") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:6] Set("SIP/patton1-08eca338", "__CALLINGPRES_SV=allowed_not_screened") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:7] SetCallerPres("SIP/patton1-08eca338", "allowed_not_screened") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:8] Set("SIP/patton1-08eca338", "_RGPREFIX=2XP: ") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:9] Set("SIP/patton1-08eca338", "CALLERID(name)=2XP: 222222222") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [111111111@from-pstn:10] Goto("SIP/patton1-08eca338", "app-announcement-4|s|1") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Goto (app-announcement-4,s,1)
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [s@app-announcement-4:1] GotoIf("SIP/patton1-08eca338", "0?begin") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [s@app-announcement-4:2] Answer("SIP/patton1-08eca338", "") in new stack
Dec 3 11:58:01 VERBOSE [3606] logger.c: -- Executing [s@app-announcement-4:3] Wait("SIP/patton1-08eca338", "1") in new stack
Dec 3 11:58:02 VERBOSE [3606] logger.c: == Spawn extension (app-announcement-4, s, 3) exited non-zero on 'SIP/patton1-08eca338'
111111111 => DID
222222222 => Cell Phone number
 

Stinger81

Joined
Oct 30, 2008
Messages
56
Likes
0
Points
0
#7
New log, with higher verbosity and debug level:
Dec 3 15:48:14 WARNING [23398] rtp.c: Unable to set TOS to 184
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: Setting NAT on RTP to Off
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: Allocating new SIP dialog for 484dc8915092ca119d4eb905b43d78b8@192.168.0.6 - INVITE (With RTP)
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: **** Received INVITE (5) - Command in SIP INVITE
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: Setting NAT on RTP to Off
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: T38 state changed to 0 on channel
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: We're settling with these formats: 0x8 (alaw)
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: Checking SIP call limits for device patton1
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: Updating call counter for incoming call
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: *** Our native formats are 0x8 (alaw)
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: *** Joint capabilities are 0x8 (alaw)
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: *** Our capabilities are 0x8 (alaw)
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: *** AST_CODEC_CHOOSE formats are 0x8 (alaw)
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: This channel will not be able to handle video.
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: build_route: Contact hop: sip:651576727@192.168.0.7:5060
Dec 3 15:48:14 DEBUG [23398] chan_sip.c: SIP/patton1-08e302c8: New call is still down.... Trying...
Dec 3 15:48:14 DEBUG [23398] devicestate.c: Notification of state change to be queued on device/channel SIP/patton1
Dec 3 15:48:14 DEBUG [23392] devicestate.c: No provider found, checking channel drivers for SIP - patton1
Dec 3 15:48:14 DEBUG [23392] chan_sip.c: Checking device state for peer patton1
Dec 3 15:48:14 DEBUG [23392] devicestate.c: Changing state for SIP/patton1 - state 4 (Invalid)
Dec 3 15:48:14 DEBUG [23400] app_queue.c: Device 'SIP/patton1' changed to state '4' (Invalid) but we don't care because they're not a member of any queue.
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Set'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:1] Set("SIP/patton1-08e302c8", "__FROM_DID=402947957") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Gosub'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:2] Gosub("SIP/patton1-08e302c8", "app-blacklist-check|s|1") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'LookupBlacklist'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [s@app-blacklist-check:1] LookupBlacklist("SIP/patton1-08e302c8", "") in new stack
Dec 3 15:48:14 DEBUG [8453] db.c: Unable to find key '651576727' in family 'blacklist'
Dec 3 15:48:14 DEBUG [8453] db.c: Unable to find key '' in family 'blacklist'
Dec 3 15:48:14 DEBUG [8453] pbx.c: Expression result is '0'
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'GotoIf'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [s@app-blacklist-check:2] GotoIf("SIP/patton1-08e302c8", "0?blacklisted") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Not taking any branch
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Return'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [s@app-blacklist-check:3] Return("SIP/patton1-08e302c8", "") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Function result is ''
Dec 3 15:48:14 DEBUG [8453] pbx.c: Expression result is '0'
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'GotoIf'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:3] GotoIf("SIP/patton1-08e302c8", "0 ?cidok") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Not taking any branch
Dec 3 15:48:14 DEBUG [8453] pbx.c: Function result is '651576727'
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Set'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:4] Set("SIP/patton1-08e302c8", "CALLERID(name)=651576727") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Function result is '"651576727" <651576727>'
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'NoOp'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:5] NoOp("SIP/patton1-08e302c8", "CallerID is "651576727" <651576727>") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Set'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:6] Set("SIP/patton1-08e302c8", "__CALLINGPRES_SV=allowed_not_screened") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'SetCallerPres'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:7] SetCallerPres("SIP/patton1-08e302c8", "allowed_not_screened") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Set'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:8] Set("SIP/patton1-08e302c8", "_RGPREFIX=2XP: ") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Function result is '651576727'
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Set'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:9] Set("SIP/patton1-08e302c8", "CALLERID(name)=2XP: 651576727") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Goto'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [402947957@from-pstn:10] Goto("SIP/patton1-08e302c8", "app-announcement-4|s|1") in new stack
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Goto (app-announcement-4,s,1)
Dec 3 15:48:14 DEBUG [8453] pbx.c: Function result is 'NO ANSWER'
Dec 3 15:48:14 DEBUG [8453] pbx.c: Expression result is '0'
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'GotoIf'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [s@app-announcement-4:1] GotoIf("SIP/patton1-08e302c8", "0?begin") in new stack
Dec 3 15:48:14 DEBUG [8453] pbx.c: Not taking any branch
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Answer'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [s@app-announcement-4:2] Answer("SIP/patton1-08e302c8", "") in new stack
Dec 3 15:48:14 DEBUG [8453] devicestate.c: Notification of state change to be queued on device/channel SIP/patton1
Dec 3 15:48:14 DEBUG [23392] devicestate.c: No provider found, checking channel drivers for SIP - patton1
Dec 3 15:48:14 DEBUG [23392] chan_sip.c: Checking device state for peer patton1
Dec 3 15:48:14 DEBUG [8453] chan_sip.c: SIP answering channel: SIP/patton1-08e302c8
Dec 3 15:48:14 DEBUG [8453] chan_sip.c: Setting framing from config on incoming call
Dec 3 15:48:14 DEBUG [8453] chan_sip.c: ** Our capability: 0x8 (alaw) Video flag: True
Dec 3 15:48:14 DEBUG [8453] chan_sip.c: ** Our prefcodec: 0x0 (nothing)
Dec 3 15:48:14 DEBUG [8453] chan_sip.c: -- Done with adding codecs to SDP
Dec 3 15:48:14 DEBUG [8453] channel.c: Internal timing is disabled (option_internal_timing=0 chan->timingfd=25)
Dec 3 15:48:14 DEBUG [8453] chan_sip.c: Done building SDP. Settling with this capability: 0x8 (alaw)
Dec 3 15:48:14 DEBUG [8453] pbx.c: Launching 'Wait'
Dec 3 15:48:14 VERBOSE [8453] logger.c: -- Executing [s@app-announcement-4:3] Wait("SIP/patton1-08e302c8", "1") in new stack
Dec 3 15:48:14 DEBUG [23392] devicestate.c: Changing state for SIP/patton1 - state 4 (Invalid)
Dec 3 15:48:14 DEBUG [23400] app_queue.c: Device 'SIP/patton1' changed to state '4' (Invalid) but we don't care because they're not a member of any queue.
Dec 3 15:48:15 DEBUG [23398] chan_sip.c: = Found Their Call ID: 484dc8915092ca119d4eb905b43d78b8@192.168.0.6 Their Tag 35073940b9f04d1 Our tag: as08d0f5f1
Dec 3 15:48:15 DEBUG [23398] chan_sip.c: **** Received ACK (6) - Command in SIP ACK
Dec 3 15:48:15 DEBUG [23398] chan_sip.c: Stopping retransmission on '484dc8915092ca119d4eb905b43d78b8@192.168.0.6' of Response 560310815: Match Found
Dec 3 15:48:15 DEBUG [23398] chan_sip.c: = Found Their Call ID: 484dc8915092ca119d4eb905b43d78b8@192.168.0.6 Their Tag 35073940b9f04d1 Our tag: as08d0f5f1
Dec 3 15:48:15 DEBUG [23398] chan_sip.c: **** Received BYE (8) - Command in SIP BYE
Dec 3 15:48:15 DEBUG [23398] chan_sip.c: Setting SIP_ALREADYGONE on dialog 484dc8915092ca119d4eb905b43d78b8@192.168.0.6
Dec 3 15:48:15 DEBUG [23398] chan_sip.c: Received bye, issuing owner hangup
Dec 3 15:48:15 DEBUG [8453] pbx.c: Spawn extension (app-announcement-4,s,3) exited non-zero on 'SIP/patton1-08e302c8'
Dec 3 15:48:15 VERBOSE [8453] logger.c: == Spawn extension (app-announcement-4, s, 3) exited non-zero on 'SIP/patton1-08e302c8'
Dec 3 15:48:15 DEBUG [8453] channel.c: Soft-Hanging up channel 'SIP/patton1-08e302c8'
Dec 3 15:48:15 DEBUG [8453] channel.c: Hanging up channel 'SIP/patton1-08e302c8'
Dec 3 15:48:15 DEBUG [8453] chan_sip.c: Hangup call SIP/patton1-08e302c8, SIP callid 484dc8915092ca119d4eb905b43d78b8@192.168.0.6)
Dec 3 15:48:15 DEBUG [8453] cdr_addon_mysql.c: cdr_mysql: inserting a CDR record.
Dec 3 15:48:15 DEBUG [8453] cdr_addon_mysql.c: cdr_mysql: SQL command as follows: INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid,userfield) VALUES ('2008-12-03 15:48:14','\"2XP: 651576727\" <651576727>','651576727','s','app-announcement-4', 'SIP/patton1-08e302c8','','Wait','1',1,1,'ANSWERED',3,'','1228315694.1569','')
Dec 3 15:48:15 DEBUG [8453] devicestate.c: Notification of state change to be queued on device/channel SIP/patton1
Dec 3 15:48:15 DEBUG [23392] devicestate.c: No provider found, checking channel drivers for SIP - patton1
Dec 3 15:48:15 DEBUG [23392] chan_sip.c: Checking device state for peer patton1
Dec 3 15:48:15 DEBUG [23392] devicestate.c: Changing state for SIP/patton1 - state 4 (Invalid)
Dec 3 15:48:15 DEBUG [23400] app_queue.c: Device 'SIP/patton1' changed to state '4' (Invalid) but we don't care because they're not a member of any queue.
Dec 3 15:48:15 VERBOSE [23398] logger.c: Really destroying SIP dialog '484dc8915092ca119d4eb905b43d78b8@192.168.0.6' Method: BYE
Anyone who received some kind of inspiration out of these logs?
 

Stinger81

Joined
Oct 30, 2008
Messages
56
Likes
0
Points
0
#8
I guess I was inspired by something, though not resulting in a solution...

Are there any network services on the cell phone network which could influence Asterisk and cause this problem?
 

Stinger81

Joined
Oct 30, 2008
Messages
56
Likes
0
Points
0
#9
We consider this issue to be resolved.
This morning he couldn't call in, he went to a KPN office and had his phone reset and this afternoon he could call in.
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,938
Messages
130,959
Members
17,632
Latest member
moaulool
Top