Happy

Snomone Free allows, if I'm correct, for 10 extensions : 8 of them have to be Snom phones, the other 2 may be other brands. Greetings, Marc

I'm using snom320 phones. I have no idea how I can actually add ulaw codec. Could you give me some clue ? Many thanks, Marc

We are on W32 (Xp). I did have problems with hold / Retrieve and Park, but after a complete restart of every extension everything seems normal. We have a normal moh when calls are parked in the park orbit. Hope it stays that way !

Seems to be another certificate is also not available : [4] 2010/11/20 05:50:52: Certificate for UTN-USERFirst-Hardware not available [4] 2010/11/20 06:50:52: Certificate for Pradeep not available Maybe this info is helpfull in any way... Marc

Ok, I found the object 'park orbit' and created one. But when I link a button using 'Park Orbit' and the number of the park orbit, it does not park. I am clearly missing something!

Interesting, Andreas : you actually managed to use the Fritzbox 7270 as a gateway between pots/isdn line and your snomone pbx ? I have a fritzbox 7170, but I could not make it a reliable gateway ...

I'm sorry, but B2BUA means ... ??

So you have to setup a park orbit first, then use that number in the extension setup : how do you setup the orbit ? I checked the manual but it was not very helpfull to me regarding park orbits...

Since my move towards Pbxnsip Version 4 (latest version), system is asking me for certificates ? *----------Logfile---- [4] 2010/11/18 16:39:09: Certificate for Pradeep not available [4] 2010/11/18 16:39:10: Certificate for UTN-USERFirst-Hardware not available *--------------------- Any explanation ? Thanks, Marc

Can anyone explain the strange codex use and transcoding that seems to be happening since I started up Pbxnsip version 4 (latest version). *--------Logfile-- Sending RTP for 3c2babd5d497-evfazu85tsm2 to 192.168.1.122:50922, codec not set yet Dialplan "Algemeen Kiesplan": Match 011999999@pbx.praktijk.be to <sip:011999999@ssw0.brussels.weepee.org;user=phone> on trunk WeePee Codec pcmu/8000 is chosen for call id 3c2babd5d497-evfazu85tsm2 Codec gsm/8000 is chosen for call id 6cf614d1@pbx Sending RTP for 6cf614d1@pbx to 91.208.12.130:26410, codec gsm/8000 Different Codecs (local pcmu/8000, remote gsm/8000), callid 3c2babd5d497-evfazu85tsm2, falling back to transcoding *-------- Many thanks !

Change the admin/ports packet size in Pbxnsip would influence connections to all trunks and phones, I suppose. Found a phone : a sipura device with a non-standard 30millisec setting!

Is TLS not a 'standard' feature in a Snom phone - Pbxnsip environment ? Is there a way to track this problem down ?

Could this have something to do with the fact, that I'm getting a 'forbidden' whenever I use a non-default trunk to call out ?

I was concerned about both. If I understand you correcly, I have to ask the voip provider to change teh 30ms packet to 20ms. There is no way to adapt pbxnsip to the provider's settings ?

Could anyone explain to me the strange codex behaviour, that seems to take place since I upgraded my system to the latest version 4 ? Log details below (don't find how to make attachements) ------------------ [4] 2010/10/25 08:13:08: Certificate for UTN-USERFirst-Hardware not available [6] 2010/10/25 08:41:09: Sending RTP for 3c26f037f183-pmfuk042dnj0 to 192.168.1.111:60040, codec not set yet [6] 2010/10/25 08:41:09: Codec pcmu/8000 is chosen for call id 3c26f037f183-pmfuk042dnj0 [6] 2010/10/25 08:45:37: Last message repeated 2 times [6] 2010/10/25 08:45:37: Sending RTP for 3c26f1443a60-eo3jprew4xti to 192.168.1.111:51430, codec not set yet [6] 2010/10/25 08:45:38: Codec pcmu/8000 is chosen for call id 3c26f1443a60-eo3jprew4xti [6] 2010/10/25 08:45:42: Last message repeated 2 times [6] 2010/10/25 08:45:42: Sending RTP for 3c26f1493088-l0rfsie8ywpl to 192.168.1.111:58142, codec not set yet [6] 2010/10/25 08:45:43: Codec pcmu/8000 is chosen for call id 3c26f1493088-l0rfsie8ywpl [6] 2010/10/25 09:01:52: Last message repeated 2 times [6] 2010/10/25 09:01:52: Sending RTP for 3c2794bb2bf4-n6h6xmpisry6 to 192.168.1.23:55170, codec not set yet [6] 2010/10/25 09:01:52: Codec pcmu/8000 is chosen for call id 3c2794bb2bf4-n6h6xmpisry6 [6] 2010/10/25 09:02:14: Last message repeated 2 times [6] 2010/10/25 09:02:14: Sending RTP for 824d122fbf0cbdbd to 192.168.1.2:5238, codec not set yet [3] 2010/10/25 09:02:14: Account 33 is not a Service Flag [3] 2010/10/25 09:02:14: Hunt group 94 wants to add 6 members [6] 2010/10/25 09:02:26: Codec pcmu/8000 is chosen for call id 6712bbf7@pbx [6] 2010/10/25 09:02:26: Sending RTP for 6712bbf7@pbx to 192.168.1.21:55946, codec pcmu/8000 [6] 2010/10/25 09:02:26: Codec pcmu/8000 is chosen for call id 824d122fbf0cbdbd [6] 2010/10/25 09:04:55: Sending RTP for 3d48f974f3b4f453 to 192.168.1.2:5240, codec not set yet [3] 2010/10/25 09:04:56: Account 33 is not a Service Flag [3] 2010/10/25 09:04:56: Hunt group 94 wants to add 6 members [6] 2010/10/25 09:05:10: Codec pcmu/8000 is chosen for call id ca1a80bc@pbx [6] 2010/10/25 09:05:10: Sending RTP for ca1a80bc@pbx to 192.168.1.21:49168, codec pcmu/8000 [6] 2010/10/25 09:05:10: Codec pcmu/8000 is chosen for call id 3d48f974f3b4f453 [6] 2010/10/25 09:06:24: Sending RTP for 05622ea9cd2c311c to 192.168.1.2:5242, codec not set yet [3] 2010/10/25 09:06:24: Account 33 is not a Service Flag [3] 2010/10/25 09:06:24: Hunt group 94 wants to add 6 members [6] 2010/10/25 09:06:36: Codec pcmu/8000 is chosen for call id 1646ddb2@pbx [6] 2010/10/25 09:06:36: Sending RTP for 1646ddb2@pbx to 192.168.1.23:57510, codec pcmu/8000 [6] 2010/10/25 09:06:36: Codec pcmu/8000 is chosen for call id 05622ea9cd2c311c [6] 2010/10/25 09:07:53: Sending RTP for 52C428498BB2667E@192.168.1.1 to 192.168.1.1:7078, codec not set yet [3] 2010/10/25 09:07:53: Hunt group 21 wants to add 6 members [6] 2010/10/25 09:07:53: Codec pcmu/8000 is chosen for call id 52C428498BB2667E@192.168.1.1 [6] 2010/10/25 09:07:57: Sending RTP for 3c279627ef8b-w9hqobmv4z5o to 192.168.1.23:51182, codec not set yet [6] 2010/10/25 09:07:57: Codec pcmu/8000 is chosen for call id 3c279627ef8b-w9hqobmv4z5o [6] 2010/10/25 09:08:59: Last message repeated 2 times [6] 2010/10/25 09:08:59: Sending RTP for 795D34D4A0751049@192.168.1.1 to 192.168.1.1:7078, codec not set yet [3] 2010/10/25 09:08:59: Hunt group 21 wants to add 6 members [6] 2010/10/25 09:08:59: Codec pcmu/8000 is chosen for call id 795D34D4A0751049@192.168.1.1 [6] 2010/10/25 09:09:21: Sending RTP for 3c2e50241a19-cgdthhcerdpi to 192.168.1.22:64732, codec not set yet [6] 2010/10/25 09:09:21: Codec pcmu/8000 is chosen for call id 3c2e50241a19-cgdthhcerdpi [6] 2010/10/25 09:13:08: Last message repeated 2 times [4] 2010/10/25 09:13:08: HTTP client: Timeout on 173.166.77.221:443 [4] 2010/10/25 09:13:08: Certificate for UTN-USERFirst-Hardware not available [6] 2010/10/25 09:14:47: Sending RTP for b53e7ab21fa8d6b0 to 192.168.1.2:5244, codec not set yet [3] 2010/10/25 09:14:47: Account 33 is not a Service Flag [3] 2010/10/25 09:14:47: Hunt group 94 wants to add 6 members [6] 2010/10/25 09:15:02: Codec pcmu/8000 is chosen for call id b53e7ab21fa8d6b0 [3] 2010/10/25 09:15:11: Hunt group 95 wants to add 6 members [6] 2010/10/25 09:15:17: Codec pcma/8000 is chosen for call id e15efdaf@pbx [6] 2010/10/25 09:15:17: Sending RTP for e15efdaf@pbx to 192.168.1.26:49152, codec pcma/8000 [6] 2010/10/25 09:15:18: Different packet size (30 and 20), callid b53e7ab21fa8d6b0, falling back to transcoding [6] 2010/10/25 09:15:18: Different packet size (20 and 30), callid e15efdaf@pbx, falling back to transcoding [6] 2010/10/25 09:17:11: Received bindRequest for user pbx.praktijk.be\13 [6] 2010/10/25 09:17:18: Sending RTP for 3c279852a67d-jqmf892xc6fd to 192.168.1.23:57276, codec not set yet --------------------------------------

Michael, The following line in the IVR DTMF list will cause the IVR

I have been testing that solution, setting max_loop to 30. It made not any difference. There does not seem to be much logic behind it, but when I start up far enough in the chain, I get to the end. Otherwise the line gets cut. Could a clean setup of Pbxnsip be a solution to my problem : 6 steps to get a call to its destination surely can't be a problem related to pbxnsip ?

Can anyone give me a hint on what log settings to use to create a log file, that shows me what happens to my incoming calls, when they get cut off by pbxnsip 4.0 ? I have been using several options on the log file, but I can't track down the necessary info ... Many thanks, Marc

I would like to upload a ringtone.xml file to pbxnsip, having alert info to link Custom1 to Custom5 ringtones to internal Snom320 ringtones. Since Pbxnsip uses its own ringtone info to differentiate between internal and external calls, and I don't know where this info is stored, I am a bit concerned about the possibility that my ringtone.xml file will erase somehow this information. Can anyone tell me what happens with the ringtone.xml file once it is uploaded to the pbx ? Many thanks, Marc

The max_loop setting does not make any difference. What log settings do I need to capture this kind of behaviour ?

It looks like that the chain of hunt groups, that I am using without any problem in version 3, blocks in version 4. What I am using when call gets to the pbx : HG 92 -> HG94 -> IVR 81 -> HG95 -> IVR85 -> HG96 The IVR's are just for announcements, no choices have to be made (Dtmf-list : !.!95! !E!95!). When I start dialing up the chain, this is what happens : 81 -> ok all the way to 96 94 -> ok all the way to 95 (call gets terminated thereafter) 92 -> ok all the way to 81 (idem) I noticed that Stage 1 and 2 of the hunt groups seem to accept only extension numbers. Calls get terminated if HG or IVR are put in for example stage 2, you have to put these in the last stage. There is a good logic for that. But I don't see any reason / setting why my chain gets broken. Could someone verify this, please. Version 4 is not usable for me unless I can get this fixed.

I would like the same feature : you can solve some of the stuff by using a hunt group, but unregistered extensions - out of the licence - would be a great idea !!