ndemou

@Vodia support: How do I send non-publicly viewable files? @Vodia PBX: does it also log some error message in the logs? @both: thanks for the prompt reply

Every once in a while a few users complain that they can't answer incoming calls. From their point of view they pick up the handset and it's like there was no call. I was able to trace 3 failed calls in two different domains (and kept detailed pcap traces and logs for the last one of them). SIP trace with carrier ====================== |Time | carrier GW | | | | PBX | |0,000 | INVITE SDP |SIP From: Anonymous ... | |(5060) ------------------> (5060) | |0,002 | 100 Trying| |SIP Status | |(5060) <------------------ (5060) | |0,010 | 200 Ok SDP |SIP Status | |(5060) <------------------ (5060) | |0,032 | ACK | |SIP Request | |(5060) ------------------> (5060) | |11,980 | BYE | |SIP Request | |(5060) <------------------ (5060) | |11,990 | 200 OK | |SIP Status | |(5060) ------------------> (5060) | SIP trace with VoIP phone ========================= |Time | PBX | | | | VoIP Phone | |0,000 | INVITE SDP |SIP From: "Anonymous"... | |(5060) ------------------> (1036) | |0,053 | 100 Trying| |SIP Status | |(5060) <------------------ (1036) | |0,185 | 180 Ringing |SIP Status | |(5060) <------------------ (1036) | |5,482 | 200 OK SDP |SIP Status | |(5060) <------------------ (1036) | |5,483 | ACK | |SIP Request | |(5060) ------------------> (1036) | |5,547 | BYE | |SIP Request | |(5060) ------------------> (1036) | |5,626 | 200 OK | |SIP Status | |(5060) <------------------ (1036) | So the PBX got a 200 OK from the phone and a few milisecs later it send a BYE back to the phone and to the carrier dropping the call. Looking at the logs to see why I see this: [8] 20140716134853: Call state for call object 143211: alerting [...] [...] [8] 20140716134854: call port 22: state code from 100 to 200 [8] 20140716134854: call port 20: state code from 200 to 200 [7] 20140716134854: 14675947-3614496522-991048@carrier: RTP pass-through mode [7] 20140716134854: 1e4c6746@pbx: RTP pass-through mode [7] 20140716134854: Determine pass-through mode after receiving response [8] 20140716134854: Call state for call object 143211: connected [...] [8] 20140716134854: call port 20: state code from 200 to 486 [8] 20140716134854: call port 22: state code from 200 to 486 [...] [...] [7] 20140716134855: Call 14675947-3614496522-991048@carrier: Clear last request [5] 20140716134855: BYE Response: Terminate 14675947-3614496522-991048@carrier [7] 20140716134855: 1e4c6746@pbx: Media-aware pass-through mode [8] 20140716134855: Clearing call port 20, SIP call id 14675947-3614496522-991048@carrier [8] 20140716134855: Remove leg 347938: call port 20, SIP call id 14675947-3614496522-991048@carrier [7] 20140716134855: Call 1e4c6746@pbx: Clear last request [5] 20140716134855: BYE Response: Terminate 1e4c6746@pbx [8] 20140716134855: Clearing call port 22, SIP call id 1e4c6746@pbx [8] 20140716134855: Remove leg 347940: call port 22, SIP call id 1e4c6746@pbx I've noticed that call port 22 that correspond to this call goes from 100 to 200 and almost immediately after that from 200 to 486. I guess these numbers correspond to SIP status so the 486 (busy) seems really strange to me. This (BYE send from pbx and log lines like the above) happened in all 3 cases that I was able to follow closely. I can provide the pcap traces and full log if needed (I just can't post them publicly)

Thanks, it makes sense and also makes things easier from our side.

Anyone?

In my test environment I'm collecting json CDRs with a ridiculously simple python script but I've a question regarding what will happen during burst of calls in a production system. The question is will the PBX POST CDRs to the web service in parallel or am I safe to expect that all CDR will be POSTed serially (every next POST just after the previous has completed)? ________________ P.S. Here is the code for anyone preferring python (apart from these lines you only need to download https://github.com/defnull/bottle/raw/master/bottle.py to make it work): from bottle import route, run, request @route('/postcdr', method='POST') def recieve_cdr(): cdr = request.json print cdr # or do what ever you want to do with the CDR return "" run(host='localhost', port=8080, debug=True)

this is an old thread but for those landing here via a web search this page http://wiki.snomone.com/index.php?title=JSON_CDR has a good enough example

the link for CentOS 32bit doesn't work (Error 404) http://vodia.com/downloads/pbx/centos32/pbxctrl-centos32-5.2.3

Well it seems that our executable is deeply broken. We also found phantom dial plan entries! Opening a specific dialplan and entering a number to the test area matches an id and a trunk that is not listed in the rules above!! This is getting out of control -- we're fighting to convince the web interface to follow our preferences and commands.

Switching to TCP doesn't seem to solve the problem with phantom calls. The situation went ugly today: we had a phantom call stuck in the ringing state and this had the side effect that one agent was for 2 hours unavailable to answer other calls. We couldn't restart the system because the other domains had a large volume of calls during that period. We can understand that "the call cleanup procedure is complicated" but at the very least we need to be able to hung up calls from the web interface.

Unfortunately we're not in hosted mode. Do you have any workarounds to suggest or is there any later version that fixes/minimizes these issues?

I'm using v4.5 and sometimes(very rarely,4 times in about 10 months) when I try to create a new extension the system complains that the extension already exists although I'm 100% that it doesn't. 3 out of 4 times a pbx restart was enough to fix it -- my memory doesn't help me on what happened with the other 1 out of 4. The 1st time I thought it was a user mistake but since then we had the time to check it over and over again. It seems to happen after deleting an extension then trying to create it again. At least that was the way it happened to us all the times. Still I wasn't able to reproduce it in our backup server. When it happens you can still create an extension with some random number. This is sometimes really annoying because we have to delay simple requests from customers for 24 hours in order to restart the system during the night and it's really hard to make an excuse for ourselves. The other problem is that almost every day we have some phantom calls. With phantom calls I mean that from the user and telephone point of view the call has either completed or has failed but the PBX displays the call on its active calls list and you can't kill them by hitting the red X (the page reloads and the call is still there). These calls may stay at that phantom state for hours (1 to 2 hours is very common). It mainly happens with failed calls but it also happens with calls at any stage (connected or alerting). This is serious because these calls are accounted towards each domains limit and probably towards the total system concurrent calls also (haven't hit that to be sure). We had a customer who somehow had 4 such calls within 5 minutes, reached his domain limit and was blocked.

The setup your're describing is what we've tried first. I'm sorry if I wasn't clear enough before. I'll try to be more detailed this time (excuse me if I'm too detailed :-) THE BASICS OF OUR SETUP We have two domains dom1 and dom2. We have an extension "extA@dom1" and an extension "extB@dom2". extB@dom2 has DDI +30222222 We have a trunk "trnkOS". It is connecting the PBX to OpenSips and it's both for incoming and outgoing calls. We have a global dial plan "dialplanOS" that sends calls via trnkOS WHAT WORKS Calls from the outside world to +30222222 reach OpenSips and are successfully connected via trnkOS to extB@dom2 Calls from extA@dom1 to the outside world are send from dialplanOS to trnkOS and are also successfully connected. WHAT DOESN'T WORK Calls from extA@dom1 to +30222222 fail. Details regarding the failure follow: Suppose that extA@dom1 is dialing 30222222. dialplanOS sends this call to trnkOS so an INVITE for sip:+30222222@OPENSIPS-IP is send to OpenSips. This INVITE seems OK (it has proper From, To and the correct SIP URI in INVITE). OpenSips knows that +30222222 is to be found at the PBX so it sends an INVITE back to the PBX with a SIP URI +30222222@PBX-IP. Note that this INVITE has the same From,To and CallID headers. The PBX is rejecting that last INVITE with a 404 message and the logs are showing something like this: [8] 20131120114754: Call from a loopback trunk [8] 20131120114754: To is "+30222222" <sip:+30222222@OPENSIPS_IP>, user 0, domain 0 [8] 20131120114754: Loopback: Set the To domain to [2] 20131120114754: Call Reject: Could not identify domain for the call 268 [8] 20131120114754: call port 268: state code from 0 to 404 Finally we do have the loopback detection turned off at admin/SIP settings.

Τhe opensips admin told as that returning an INVITE with diferent From/To tags is possible but requires extensive changes so if you have any other ideas that might be easier to implement we'll be glad to read them

That's how we do it. PS I'm waiting for the opensips admin to try and configure it so that it's sending the call back with a different from tag as per your suggestion and will report if that fixes my problem

Thanks for the prompt reply! Yes, loopback detection is indeed turned off. Regarding this point The SIP URI is like this (1.2.3.4 is the IP of the pbx -- there is no reference to the callee domain as it is not known to either the caller or the opensips server): INVITE sip:+30123456789@1.2.3.4 SIP/2.0. I will make more tests and come back to you with a trace

I have a pbxnsip server with a trunk to an opensips server that routes outgoing calls. My problem is with calls from an extension of domain #A to a DDI of another domain. I know that using the "try loopback" option is discouraged for big installations so I've asked the admin of the opensips server to return such calls back to the PBX (based on the DDI). He tried two diferent methods but both fail: Method #1: when ever an INVITE was send to the opensips server it was sending an INVITE back (with the same callid). The pbx was rejecting such calls with a 404 message and the logs were showing something like this: Method #2: when ever an INVITE was send to the opensips server it was sending back a "sip 300 Redirect" like this: The pbx is ACKing this Redirects but then does something strange: The caller sees his extension on the display and the logs seem to suggest that the pbx is trying to call CallerExtension@PbxIp. See bellow (8 is the extension number of the caller) Any ideas about what should a working setup be like? I'll need to make this work in both versions 4 and 5. Nick

In my version 4 installation I have set Settings -> Appearance -> Help link to http://mycompany.com/pbx/ but all the help links continue to point to the original snomone help. Any ideas?

is there any workaround? (because changing the carrier is not easy)

It doesn't have to do anything with the SIP service provider because I get the same behaviour when I call from a PBX extension (no trunk involved). Here is the test I perform: I'm calling from an extension in the same domain as the calling card account and... if I set "Callback: off" tcpdumps captures a "SIP/2.0 200 Ok." from the PBX and I get these lines in the logs: [8] 20130717115501: Play audio_en/ex_enter_extension_number.wav, caching false [8] 20130717115501: call port 400: state code from 0 to 200 [8] 20130717115503: Play space20, caching false but if I set "Callback: on" tcpdumps captures a "SIP/2.0 183 Session Progress." from the PBX and I get these lines in the logs: [8] 20130717115526: Play audio_en/ex_enter_extension_number.wav, caching false [8] 20130717115526: call port 401: state code from 0 to 183 [8] 20130717115527: Play space20, caching false no SIP message "200 Ok" will follow after this point. So the PBX for some reason wont answer the call with a "200 Ok" in the second case.

I'm using a calling card account without call-back just fine. However if I check the call-back option, my calls to the calling card don't get answered (I'm hearing only ringing tones and no "please enter your extension" prompt). Some facts and thoughts: 1) it seems that the system answers the call with early audio (I see "call port 45: state code from 100 to 183") and it plays back the prompt (I see "Play audio_en/ex_enter_extension_number.wav") but the audio doesn't reach the caller 2) the problem appears in 99% of the calls. This 99% gets in from my main trunk to the outside world 3) for the 1% of the calls that get in from a direct trunk with another PBX I _do_ hear the "please enter your extension" prompt 4) I've tested with versions 3 and 4 It seems to me very likely that the telco on the other side of the trunk will never pass audio until the call is considered connected (and the caller gets billed for the audio they listen to). Any ideas? [8] 20130716115832: Trunk: Check if the call to +XXXXXX0042 comes from the cell phone <MY-ANI> [8] 20130716115832: To is "+XXXXXX0042" <sip:+XXXXXX0042@<PBX-IP>;user=phone>, user 2495, domain 270 [8] 20130716115832: To user 700 [8] 20130716115832: Trying to match number +XXXXXX0042 with ERE ([0-9]*) [8] 20130716115832: Send call to extension ERE returned +XXXXXX0042 [5] 20130716115832: Global trunk <INBOUND-TRUNK>@donotdelete.com sends call to 700 in domain <DOMAIN> [8] 20130716115832: Set the To domain based on To user 700@<DOMAIN> [8] 20130716115832: Call state for call object 9467: idle [7] 20130716115832: Call port 258: set_codecs for 28df04006923-51e524f0-3b03bc98-3b47eb28-2fd2c@127.0.0.1 codecs "18",> [8] 20130716115832: Play audio_en/ex_enter_extension_number.wav, caching false [8] 20130716115832: call port 258: state code from 0 to 183 [6] 20130716115832: Call-leg 258: Codec g729/8000 is chosen for call id 28df04006923-51e524f0-3b03bc98-3b47eb28-2fd2c@> [5] 20130716115832: set codec: codec g729/8000 is set to call-leg 258 [8] 20130716115833: Play space20, caching false [8] 20130716115833: call port 258: state code from 183 to 183 [8] 20130716115835: Play audio_en/ex_enter_extension_number.wav, caching false [8] 20130716115835: call port 258: state code from 183 to 183 [8] 20130716115836: rtp_hangup: call port 254, too early to disconnect [8] 20130716115836: rtp_hangup: call port 255, too early to disconnect [8] 20130716115837: Play space20, caching false [8] 20130716115837: call port 258: state code from 183 to 183 [8] 20130716115839: Play audio_en/ex_enter_extension_number.wav, caching false [8] 20130716115839: call port 258: state code from 183 to 183 [8] 20130716115840: Play space20, caching false [8] 20130716115840: call port 258: state code from 183 to 183 [8] 20130716115842: Play audio_en/ex_enter_extension_number.wav, caching false [8] 20130716115842: call port 258: state code from 183 to 183 [8] 20130716115844: Play space20, caching false [8] 20130716115844: call port 258: state code from 183 to 183 [8] 20130716115846: Play audio_en/ex_enter_extension_number.wav, caching false [8] 20130716115846: call port 258: state code from 183 to 183 [8] 20130716115848: Play space20, caching false [8] 20130716115848: call port 258: state code from 183 to 183 [8] 20130716115850: Play audio_en/ex_enter_extension_number.wav, caching false [8] 20130716115850: call port 258: state code from 183 to 183 [8] 20130716115851: Play space20, caching false [8] 20130716115851: call port 258: state code from 183 to 183

Many thanks for the help, I guess I'll find a way workaround it.

you're probably right --the content-type should probably be there-- is there something I can do to fix this?

Can't see my attachment -- retrying trace.pcap.zip

It's really is not from the PBX. It's comming from the switch in response to the 200 OK that the PBX sends. What I don't know is whether there is something wrong in the contents of the 200 OK that causes the switch to complain. I'm attaching a trace in pcap format. Can you please have a look?

The PBX gets a SIP UPDATE message from a TELES switch, responds with 200 Ok and then gets a 400 BAD REQUEST. Do you have any idea why I get the BAD REQUEST response? 10:45:11.095852 IP SW.ITCH.ADD.RES.sip > MY.IP.ADD.RES.sip: SIP, length: 731 UPDATE sip:30ANUMBER@MY.IP.ADD.RES:5060;transport=udp SIP/2.0ia: SIP/2.0/UDP SW.ITCH.ADD.RES:5060;branch=z9hG4bK000423DF692817F0347971497FBE From: <sip:30BNUMBER@SW.ITCH.ADD.RES>;tag=8PFK451ICE30000E1D00002l009D4CK0BRRD5Q To: "lala" <sip:30ANUMBER@118408.z89.vpbx.gr;user=phone>;tag=602234505 Call-ID: 90459667@pbx CSeq: 19074 UPDATE Contact: <sip:30BNUMBER@SW.ITCH.ADD.RES:5060> Content-Type: application/sdp Max-Forwards: 70 Supported: 100rel, timer, replaces Content-Length: 213 v=0 o=- 5772220130429104508 1796079628 IN IP4 178.59.102.4 s=session c=IN IP4 IP.AD.DR.81 t=0 0 m=audio 11864 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv 10:45:11.099819 IP MY.IP.ADD.RES.sip > SW.ITCH.ADD.RES.sip: SIP, length: 646 SIP/2.0 200 Ok Via: SIP/2.0/UDP SW.ITCH.ADD.RES:5060;branch=z9hG4bK000423DF692817F0347971497FBE From: <sip:30BNUMBER@SW.ITCH.ADD.RES>;tag=8PFK451ICE30000E1D00002l009D4CK0BRRD5Q To: "lala" <sip:30ANUMBER@118408.z89.vpbx.gr;user=phone>;tag=602234505 Call-ID: 90459667@pbx CSeq: 19074 UPDATE Contact: <sip:30ANUMBER@MY.IP.ADD.RES:5060;transport=udp> Content-Length: 251 v=0 o=- 608716073 608716074 IN IP4 MY.IP.ADD.RES s=- c=IN IP4 MY.IP.ADD.RES t=0 0 m=audio 57278 RTP/AVP 8 101 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=rtcp-xr:rcvr-rtt=all voip-metrics a=sendrecv 10:45:11.100879 IP SW.ITCH.ADD.RES.sip > MY.IP.ADD.RES.sip: SIP, length: 424 SIP/2.0 400 Bad Request Via: SIP/2.0/UDP MY.IP.ADD.RES:5060;branch=z9hG4bK-ff1858bf689bc0383e22bbb428dfa383;rport=5060;received=MY.IP.ADD.RES From: "lala" <sip:30ANUMBER@118408.z89.vpbx.gr;user=phone>;tag=602234505 To: <sip:30BNUMBER@SW.ITCH.ADD.RES>;tag=8PFK451ICE30000E1D00002l009D4CK0BRRD5Q Call-ID: 90459667@pbx CSeq: 5652 INVITE Reason: SIP;cause=400;text="Bad Request" Content-Length: 0