karim.makki

Hi everyone, I recently upgraded a SnomOne 4.3.5021 to 4.5.0.1090 Epsilon on a Debian system I was using it for two domains with a Green licence. There was a problem with the version 4.3.3981 which prevented the first domain to emit calls when a second domain was created. In fact the sip username used for the hash authentication in the invite was the username of the second domain, even when passing calls from the first domain. The way to bypass this bug was to set the field "Remote Party/Privacy Indication" to "Remote Party ID" This bug was fixed in the newer versions (i tested up until 4.3.5021) but it reappears in the Epsilon version. The solution is again to set the field "Remote Party/Privacy Indication" to "Remote Party ID" Regards

Hi Broz, Thank you for your response, i will try to test this on a test platform. Meanwhile, Snom have released the new 4.5 versions, and as i saw on these versions we can assign a custom ringback tone to hunt groups. Did the upgrade today, and all incoming calls were failing lol So i was in the obligation to roll back to 4.3-5021 Will try again this evening to see what was going wrong

Otherwise, i don't know if you were suggesting this earlier, but i could replace the global ringback.wav by the customized one, then i could redefine a customized ringback for each extension which would be the default renamed ringback.wav file Do you think this would work?

In fact the global scenario is as follows: - Someone calls the general number of the office, and arrives on an auto attendant - Dependant on the time of call, the AA redirects the call to a message stating that the office is closed, or make the call ring a group of phones. - If the call is reveived during open hours, the caller should be hearing a message telling him that the call will be treated shortly. At the same time, the phones should be ringing. The scenario i managed to configure is the same as above, only with one exception. The "Your call will be treated shortly" message is played, then the phones start to ring. So this actually increases the waiting time of the caller (the message is approximately 25 seconds long). This is why i thought of having a custom ringback tone on the corresponding hunt group.

Hi again, I tried both <rf> and <rb> with the customized ringback tone in the corresponding xml of the hunt group, but when i call the hunt group i always have the normal ringback and not the one specified in the xml file.

Hello, in fact the cusomized ringback should be applied to the hunt group. should i try to add the RF to the corresponding hunt group under the hunts directory? Thanks

I tried searching for the RF in the users xml files, but i only have the following values: <alias> <ani> <dial_plan> <domain> <epid> <id> <type> i couldn't find the RB value neither on the domain xml file should i define the RF value in the corresponding extension? if so, could you explain to my the syntax to use please? Thank you

So there is no other way to do it? i will try to suggest this to the customer to see if it's acceptable. Thanks

Hello, In fact to do this scenario, i was able to configure it via the Auto Attendant. But our customer wishes that the phones should ring at the same time the caller is hearing the message. Thank you

Hello, Thank you for your reply. In fact the Auto Attendant initially reveives the call, and then redirects it to a hunt group in function of the time of the day. I have already defined the corresponding messages to play on the AutoAttendant, but if i define the redirection destination, it doesn't play the message before redirecting. that's why i thought of changing the ringback tone. Best wishes for 2012

Oh btw, i forgot te specify that i'm running a SnomGreen version 4.3.0.5021 (Linux) Thanks

Hello, I was wondering if it's possible to specify a custom ringback tone on hunt groups. I've been trying but i couldn't get it to work. In fact even if i specify one extension in the hunt group, and on that extension i configure the custom ringback tone, when calling the hunt group it doesn't work. but when calling the extension directly, i have the customized ringback. Any ideas? Thank you and happy holidays

Hello, In fact for the SnomOne to be able to support name lookup for outbound calls, it must be configured in the snom_3xx_phone.xml file, accessible from "Web page control" in the admin menu. The lines that must be present are the following, in the section "mobileTelephoneNumber</ldap_number_attributes>": <ldap_server>{ip-adr}</ldap_server> <ldap_port>{ldap-port}</ldap_port> if {ip-adr} and {ldap-port} are not there, the phone would not be provisioned with ldap server (which is the SnomOne) Regards, Karim Makki

Nevertheless, it works on a Snom821 using firmware version 8.4.31

Hello, Thank you for your reply. I tried to search to verify if the LDAP was enabled or not on the IPBX, but couldn't find it anywhere. Would you please indicate where i could find the option to enable/disable LDAP? Thanks, Karim Makki

Hello, We have a SnomBlue installed on a Debian5 virtual machine, on which are connected 68 Snom phones. Amongst the phones, we monstly have Snom300, few Snom320, and two Snom370. The Snom320 and Snom370 are provisionned on the IPBX. The problem is that we would like to see the name associated with the extension we are trying to call. When extension 401 for example calls 402, we would like to see the name of the person on extension 402. We already have that feature on incoming calls, is it possible to have it on outgoing calls too? I already tried integrating the number in the common address book, but that doesn't solve the problem. PS: IPBX release: 5009 (will upgrade to 5020 soon) Phones' firmware: 8.4.31 (already tried 8.4.18 and 8.4.32, doesn't solve my problem) I would appreciate any help, Regards, Karim Makki

Hello, The problem reappeared alone today on all domains, the same way it disappeared Did you do more tests on this issue? Thanks

Ok, will let you know if the issue reappears (i hope not ). Thanks for your replies. Regards

Here is the logfile level 8 on both tries (*02 and *02401) [8] 2011/09/09 14:54:44: Call from a trunk 10 [8] 2011/09/09 14:54:44: Trunk Corea-MS@ipbx.corea.mystream.org has country code not set, area code not set [8] 2011/09/09 14:54:44: To is <sip:401@109.70.19.42;user=phone>, user 0, domain 1 [5] 2011/09/09 14:54:44: Domain trunk Corea-MS@ipbx.corea.mystream.org sends call to 401 in domain ipbx.corea.mystream.org [8] 2011/09/09 14:54:44: Set the To domain based on To user 401@ipbx.corea.mystream.org [8] 2011/09/09 14:54:44: Call state for call object 2490: idle [8] 2011/09/09 14:54:44: Call state for call object 2490: alerting [8] 2011/09/09 14:54:44: Play audio_moh/noise.wav [7] 2011/09/09 14:54:44: set_codecs: for 76a9b0611d5f4b29629cea0c787e3a6b@87.98.200.138 codecs "0 8", codec_preference count 3 [7] 2011/09/09 14:54:44: set_codecs: for b76d0169@pbx codecs "", codec_preference count 7 [7] 2011/09/09 14:54:44: Set packet length to 20 [8] 2011/09/09 14:54:44: Play audio_fr/ringback.wav [6] 2011/09/09 14:54:44: Codec pcmu/8000 is chosen for call id 76a9b0611d5f4b29629cea0c787e3a6b@87.98.200.138 [8] 2011/09/09 14:54:47: Could not find a trunk (5 trunks) [8] 2011/09/09 14:54:47: Using outbound proxy sip:80.13.50.65:2048;transport=udp because UDP packet source did not match the via header [8] 2011/09/09 14:54:48: Tagging request with existing tag [7] 2011/09/09 14:54:48: Set packet length to 20 [6] 2011/09/09 14:54:48: Sending RTP for 3c27b09d044c-5bg96ovz7hqh to 10.8.1.78:58186, codec not set yet [8] 2011/09/09 14:54:48: Call from an user 402 [8] 2011/09/09 14:54:48: To is <sip:*02@ipbx.corea.mystream.org;user=phone>, user 0, domain 6 [8] 2011/09/09 14:54:48: From user 402 [8] 2011/09/09 14:54:48: Set the To domain based on From user 402@ipbx.corea.mystream.org [8] 2011/09/09 14:54:48: Call state for call object 2491: idle [8] 2011/09/09 14:54:48: Call state for call object 2490: connected [7] 2011/09/09 14:54:48: set_codecs: for 3c27b09d044c-5bg96ovz7hqh codecs "", codec_preference count 7 [7] 2011/09/09 14:54:48: Set packet length to 20 [6] 2011/09/09 14:54:48: Codec pcmu/8000 is chosen for call id 3c27b09d044c-5bg96ovz7hqh [6] 2011/09/09 14:54:48: Last message repeated 2 times [7] 2011/09/09 14:54:48: 76a9b0611d5f4b29629cea0c787e3a6b@87.98.200.138: RTP pass-through mode [7] 2011/09/09 14:54:48: 3c27b09d044c-5bg96ovz7hqh: RTP pass-through mode [7] 2011/09/09 14:54:48: Call 3c27b09d044c-5bg96ovz7hqh: Clear last request [6] 2011/09/09 14:54:48: Sending RTP for 3c27b09d044c-5bg96ovz7hqh to 80.13.50.65:58186, codec pcmu/8000 [7] 2011/09/09 14:54:48: Call b76d0169@pbx: Clear last request [7] 2011/09/09 14:54:48: Call b76d0169@pbx: Clear last INVITE [5] 2011/09/09 14:54:48: INVITE Response 487 Request Terminated: Terminate b76d0169@pbx [8] 2011/09/09 14:54:50: Hangup: Call 231 not found [7] 2011/09/09 14:54:50: 3c27b09d044c-5bg96ovz7hqh: Media-aware pass-through mode [8] 2011/09/09 14:54:50: Hangup: Call 231 not found [7] 2011/09/09 14:54:50: Call 3c27b09d044c-5bg96ovz7hqh: Clear last request [5] 2011/09/09 14:54:50: BYE Response: Terminate 3c27b09d044c-5bg96ovz7hqh [5] 2011/09/09 14:54:58: Identify trunk (IP address and DID match) 10 [7] 2011/09/09 14:54:58: Set packet length to 20 [6] 2011/09/09 14:54:58: Sending RTP for 231b66cd00cc37a43ebcd871419765aa@87.98.200.138 to 87.98.200.138:19970, codec not set yet [8] 2011/09/09 14:54:58: Call from a trunk 10 [8] 2011/09/09 14:54:58: Trunk Corea-MS@ipbx.corea.mystream.org has country code not set, area code not set [8] 2011/09/09 14:54:58: To is <sip:401@109.70.19.42;user=phone>, user 0, domain 1 [5] 2011/09/09 14:54:58: Domain trunk Corea-MS@ipbx.corea.mystream.org sends call to 401 in domain ipbx.corea.mystream.org [8] 2011/09/09 14:54:58: Set the To domain based on To user 401@ipbx.corea.mystream.org [8] 2011/09/09 14:54:58: Call state for call object 2492: idle [8] 2011/09/09 14:54:58: Call state for call object 2492: alerting [8] 2011/09/09 14:54:58: Play audio_moh/noise.wav [7] 2011/09/09 14:54:58: set_codecs: for 231b66cd00cc37a43ebcd871419765aa@87.98.200.138 codecs "0 8", codec_preference count 3 [7] 2011/09/09 14:54:58: set_codecs: for 1bcf3e62@pbx codecs "", codec_preference count 7 [7] 2011/09/09 14:54:58: Set packet length to 20 [8] 2011/09/09 14:54:58: Play audio_fr/ringback.wav [6] 2011/09/09 14:54:58: Codec pcmu/8000 is chosen for call id 231b66cd00cc37a43ebcd871419765aa@87.98.200.138 [8] 2011/09/09 14:55:02: Could not find a trunk (5 trunks) [8] 2011/09/09 14:55:02: Using outbound proxy sip:80.13.50.65:2048;transport=udp because UDP packet source did not match the via header [8] 2011/09/09 14:55:02: Tagging request with existing tag [7] 2011/09/09 14:55:02: Set packet length to 20 [6] 2011/09/09 14:55:02: Sending RTP for 3c27b0a9f33d-8ten0xrimcig to 10.8.1.78:62090, codec not set yet [8] 2011/09/09 14:55:02: Call from an user 402 [8] 2011/09/09 14:55:02: To is <sip:*02401@ipbx.corea.mystream.org;user=phone>, user 0, domain 6 [8] 2011/09/09 14:55:02: From user 402 [8] 2011/09/09 14:55:02: Set the To domain based on From user 402@ipbx.corea.mystream.org [8] 2011/09/09 14:55:02: Call state for call object 2493: idle [8] 2011/09/09 14:55:02: Call state for call object 2492: connected [7] 2011/09/09 14:55:02: set_codecs: for 3c27b0a9f33d-8ten0xrimcig codecs "", codec_preference count 7 [7] 2011/09/09 14:55:02: Set packet length to 20 [6] 2011/09/09 14:55:02: Codec pcmu/8000 is chosen for call id 3c27b0a9f33d-8ten0xrimcig [6] 2011/09/09 14:55:02: Last message repeated 2 times [7] 2011/09/09 14:55:02: 231b66cd00cc37a43ebcd871419765aa@87.98.200.138: RTP pass-through mode [7] 2011/09/09 14:55:02: 3c27b0a9f33d-8ten0xrimcig: RTP pass-through mode [7] 2011/09/09 14:55:02: Call 3c27b0a9f33d-8ten0xrimcig: Clear last request [6] 2011/09/09 14:55:02: Sending RTP for 3c27b0a9f33d-8ten0xrimcig to 80.13.50.65:62090, codec pcmu/8000 [7] 2011/09/09 14:55:02: Call 1bcf3e62@pbx: Clear last request [7] 2011/09/09 14:55:02: Call 1bcf3e62@pbx: Clear last INVITE [5] 2011/09/09 14:55:02: INVITE Response 487 Request Terminated: Terminate 1bcf3e62@pbx [8] 2011/09/09 14:55:06: Hangup: Call 241 not found [7] 2011/09/09 14:55:06: 231b66cd00cc37a43ebcd871419765aa@87.98.200.138: Media-aware pass-through mode [8] 2011/09/09 14:55:06: Hangup: Call 241 not found [7] 2011/09/09 14:55:06: Call 231b66cd00cc37a43ebcd871419765aa@87.98.200.138: Clear last request [5] 2011/09/09 14:55:06: BYE Response: Terminate 231b66cd00cc37a43ebcd871419765aa@87.98.200.138 Kind Regards

Hello again, The first call that you see on the domain 1 is the initial incoming call, and not the attempt to do a directed pickup call. I don't know why the SnomBlue is receiving the call on Domain1; maybe all incoming calls are routed to domain1 by default, then the SnomBlue searches for the corresponding domain? Concerning the incoming call ringing directly on extension 401, in fact we controle the server on which we have the registered trunk. so i routed a call a bit in a hurry directly to 401, since i haven't issigned a 10 digit number to that extension. The customer facing this problem will have all it's incoming calls routed via our voip plateform next Thursday (15 September), so i appreciate if we could pass this issue to an urgent status Thanks again EDIT: Hello again, i did some call pickup tests with the "localhost" domain (successfully), and when i returned to test with the domain where the problem occurs, oddly i could intercept with no problem! i will send in another reply the call pickup log.

Hello, After deactivation of one of the domain trunks on the Snom Blue (now there are three), we are able to intercept when using *87 A directed Call pickup (*87401) returns the same error as mentioned above. We tried to replace the *87 with *02, and we have the same symptoms (blind call pickup successful, directed call pickup fails) Here is the call log when using *87 then *87401: [5] 2011/09/08 16:32:11: Identify trunk (IP address and DID match) 10 [7] 2011/09/08 16:32:11: Set packet length to 20 [6] 2011/09/08 16:32:11: Sending RTP for 30e0ad9e56cdfcc04f20c1661bac586f@87.98.200.138 to 87.98.200.138:14516, codec not set yet [8] 2011/09/08 16:32:11: Call from a trunk 10 [8] 2011/09/08 16:32:11: Trunk Corea-MS@ipbx.corea.mystream.org has country code not set, area code not set [8] 2011/09/08 16:32:11: To is <sip:401@109.70.19.42;user=phone>, user 0, domain 1 [5] 2011/09/08 16:32:11: Domain trunk Corea-MS@ipbx.corea.mystream.org sends call to 401 in domain ipbx.corea.mystream.org [8] 2011/09/08 16:32:11: Set the To domain based on To user 401@ipbx.corea.mystream.org [8] 2011/09/08 16:32:11: Call state for call object 2327: idle [8] 2011/09/08 16:32:11: Call state for call object 2327: alerting [8] 2011/09/08 16:32:11: Play audio_moh/noise.wav [7] 2011/09/08 16:32:11: set_codecs: for 30e0ad9e56cdfcc04f20c1661bac586f@87.98.200.138 codecs "0 8", codec_preference count 3 [7] 2011/09/08 16:32:11: set_codecs: for e1d13890@pbx codecs "", codec_preference count 7 [7] 2011/09/08 16:32:11: Set packet length to 20 [8] 2011/09/08 16:32:12: Play audio_fr/ringback.wav [6] 2011/09/08 16:32:12: Codec pcmu/8000 is chosen for call id 30e0ad9e56cdfcc04f20c1661bac586f@87.98.200.138 [7] 2011/09/08 16:32:12: Call e1d13890@pbx: Clear last request [8] 2011/09/08 16:32:15: Could not find a trunk (5 trunks) [8] 2011/09/08 16:32:15: Using outbound proxy sip:80.13.50.65:52845;transport=udp because UDP packet source did not match the via header [8] 2011/09/08 16:32:15: Tagging request with existing tag [7] 2011/09/08 16:32:15: Set packet length to 20 [6] 2011/09/08 16:32:15: Sending RTP for NDYwYzc4ODY4NDE0NGUwYThlNjNhMzA3NWE2YzM3MWQ. to 80.13.50.65:40030, codec not set yet [8] 2011/09/08 16:32:15: Call from an user 402 [8] 2011/09/08 16:32:15: To is <sip:*87401@ipbx.corea.mystream.org:5060>, user 0, domain 6 [8] 2011/09/08 16:32:15: From user 402 [8] 2011/09/08 16:32:15: Set the To domain based on From user 402@ipbx.corea.mystream.org [8] 2011/09/08 16:32:15: Call state for call object 2328: idle [4] 2011/09/08 16:32:15: Ignoring directed pickup request for call leg because the difference of -57526214 is too short [7] 2011/09/08 16:32:15: set_codecs: for NDYwYzc4ODY4NDE0NGUwYThlNjNhMzA3NWE2YzM3MWQ. codecs "", codec_preference count 7 [7] 2011/09/08 16:32:15: Set packet length to 20 [8] 2011/09/08 16:32:18: Could not find a trunk (5 trunks) [8] 2011/09/08 16:32:18: Using outbound proxy sip:80.13.50.65:52845;transport=udp because UDP packet source did not match the via header [8] 2011/09/08 16:32:19: Tagging request with existing tag [7] 2011/09/08 16:32:19: Set packet length to 20 [6] 2011/09/08 16:32:19: Sending RTP for MjA4NDdlMzI4NjE4MjAwNjc1OTFjZTU5MWI2ZGMzZDM. to 80.13.50.65:40034, codec not set yet [8] 2011/09/08 16:32:19: Call from an user 402 [8] 2011/09/08 16:32:19: To is <sip:*87@ipbx.corea.mystream.org:5060>, user 0, domain 6 [8] 2011/09/08 16:32:19: From user 402 [8] 2011/09/08 16:32:19: Set the To domain based on From user 402@ipbx.corea.mystream.org [8] 2011/09/08 16:32:19: Call state for call object 2329: idle [8] 2011/09/08 16:32:19: Call state for call object 2327: connected [7] 2011/09/08 16:32:19: set_codecs: for MjA4NDdlMzI4NjE4MjAwNjc1OTFjZTU5MWI2ZGMzZDM. codecs "", codec_preference count 7 [7] 2011/09/08 16:32:19: Set packet length to 20 [6] 2011/09/08 16:32:19: Codec pcmu/8000 is chosen for call id MjA4NDdlMzI4NjE4MjAwNjc1OTFjZTU5MWI2ZGMzZDM. [6] 2011/09/08 16:32:19: Last message repeated 2 times [7] 2011/09/08 16:32:19: 30e0ad9e56cdfcc04f20c1661bac586f@87.98.200.138: RTP pass-through mode [7] 2011/09/08 16:32:19: MjA4NDdlMzI4NjE4MjAwNjc1OTFjZTU5MWI2ZGMzZDM.: RTP pass-through mode [7] 2011/09/08 16:32:19: Call e1d13890@pbx: Clear last request [7] 2011/09/08 16:32:19: Call e1d13890@pbx: Clear last INVITE [5] 2011/09/08 16:32:19: INVITE Response 487 Request Terminated: Terminate e1d13890@pbx [6] 2011/09/08 16:32:19: Sending RTP for MjA4NDdlMzI4NjE4MjAwNjc1OTFjZTU5MWI2ZGMzZDM. to 80.13.50.65:2880, codec pcmu/8000 [8] 2011/09/08 16:32:25: Hangup: Call 347 not found [7] 2011/09/08 16:32:25: MjA4NDdlMzI4NjE4MjAwNjc1OTFjZTU5MWI2ZGMzZDM.: Media-aware pass-through mode [8] 2011/09/08 16:32:25: Hangup: Call 347 not found [7] 2011/09/08 16:32:25: Call MjA4NDdlMzI4NjE4MjAwNjc1OTFjZTU5MWI2ZGMzZDM.: Clear last request [5] 2011/09/08 16:32:25: BYE Response: Terminate MjA4NDdlMzI4NjE4MjAwNjc1OTFjZTU5MWI2ZGMzZDM. Thanks in advance

Hello "support", Would you have feedback on this issue plz? Thanks

Hi again, The *87 was tested today, but i have the same problem as before (when using another star code) Here is the Error: Ignoring directed pickup request for call leg because the difference of -920966761 is too short PS: The negative value changes form one call to another Best Regards, Karim Makki

Hello, Thanks for your reply. In fact i haven't had time to test with the client when using the default star code, i will test it and get back with the results as soon as possible. During the tests, we tried to intercept when there was only one call on the extension Regards

Hello everyone, I have been encountering this error too on a multi-domain snomblue. [4] 2011/08/25 16:37:26: Ignoring directed pickup request for call leg because the difference of -1266815360 is too short This is the installation in general: - Snom telephones are registered on the SnomBlue (which is not installed on the same network) - There are three domains at the moment - Telephones are configured manually, and not provisionned - The phones have 3 digit extensions that begin with a 2 or a 3 - The call pickup failed with the same error when using *02 and *82 as a Call Pickup star code - The SnomBlue is on the 3981 version, linux distribution - Note that another client on the same SnomBlue is not having problems with Call Pickup (and using the default *87 starcode) Kurt, were you able to solve the issue? could you please provide feedback if so? Thank you