SFX Group Posted April 17, 2012 Report Share Posted April 17, 2012 Hi I have 2 Snom 360, both Auto config, i can call one to the other no problems, however if i put x21 = Snom 360 (fw = 8.4.35) x42 = Snom 360 (fw = 8.4.35) Call one to the other no problems, however put a trunk to call extension directly (21) no problem, do it for 42 and it acts like DND is on (when its not). Put both extensions in a hunt group, 42 acts like DND is on, again call extenstion from any other and its fine.... This perticular phone was bought used, however we TFTP the firmware so it was wiped completely, as a check if i press DND on x42, it shows in the Accounts as DND "yes" so thats working, why will this extension not accept external calls? Quote Link to comment Share on other sites More sharing options...
pbx support Posted April 17, 2012 Report Share Posted April 17, 2012 Do you have the SIP trace from phone or the PBX? Quote Link to comment Share on other sites More sharing options...
SFX Group Posted April 18, 2012 Author Report Share Posted April 18, 2012 I'll reset all logs (PBX, working extenstion and bad extension) then call in and send all 3 logs. Quote Link to comment Share on other sites More sharing options...
SFX Group Posted April 20, 2012 Author Report Share Posted April 20, 2012 Do you have the SIP trace from phone or the PBX? I have the trace logs, i reset all logs so only this call shows up... PBX = 192.168.1.63 21 = 192.168.1.112 (Ashley Office) - working extension, no problems i can see 42 = 192.168.1.113 (Lounge) - rings on internal calls, nothing on external (as wih this test) 72 = Hunt group, 21, 41, 42 for 15 seconds then 821 as last extension External trunk > 72 (hunt group, 21, 41, 42 for 15 seconds then 821) Extension 21 rang as normal Extenstion 42 showed flashing BLF (as 21 does) however doesnt ring and when picking up doesnt connect the call. Does the same when calling huntgroup 72 Works fine if i call the extenstion directly from another phone. Extenstion 21 was bought new Extenstion 42 was second hand and needed TFTP to clear all details including passwords. LOG PBX Log Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 20, 2012 Report Share Posted April 20, 2012 Looks like the phone on 192.168.1.113 is configured not to accept u-law codes: SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/UDP 192.168.1.63:5060;branch=z9hG4bK-e97e9b7916393e75fe379f5e4f13718a;rport=5060 From: "BEVERLY MAY" <sip:5198417838@174.137.63.206;user=phone>;tag=34237 To: <sip:2264751002@206.248.136.39:5060;user=phone>;tag=qy7opijznr Call-ID: 11be718c@pbx CSeq: 9947 INVITE Contact: <sip:42@192.168.1.113:2049;line=dexwgw6y>;reg-id=1 Warning: 304 x-snom-adr "No supported media type found" Content-Length: 0 Quote Link to comment Share on other sites More sharing options...
SFX Group Posted April 21, 2012 Author Report Share Posted April 21, 2012 Thanks for spotting that, however this phone is configured by Provisioning, so how do i change that? Both phones RTP page on the Identity are identical...! Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 21, 2012 Report Share Posted April 21, 2012 You probably have to factory reset the phone and provision it again. The PnP from the PBX does not provision all settings which are available on the phone. Quote Link to comment Share on other sites More sharing options...
SFX Group Posted April 21, 2012 Author Report Share Posted April 21, 2012 Factory reset being TFTP? If so i'll try factory with v8 firmware then. Quote Link to comment Share on other sites More sharing options...
SFX Group Posted April 21, 2012 Author Report Share Posted April 21, 2012 UPDATE >> Turns out it appears to be SNOM ONE and not the phone....!!! << I downloaded the new firmware (8.7.3.7 which has taken the anolog clock off but will start another thread on that), submitted a reset from the webpage, it reset, it then updated to the new firmware (as i had the link in PnP in SNOM ONE), it provisioned by design, it still didnt work. I can make calls from 21 to 42 (42 was the "suspect" phone), i can put 42 in to the trunk and calls come in to 42 as designed. I have the HUNT Group, its ONLY the hunt group that doesnt route the call to the phone so whats wrong with the hunt group? Ive tried another Hunt group and that doesnt work either!!!! Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 21, 2012 Report Share Posted April 21, 2012 On a second look, seems that the phone was response was because the port on the PBX was set to zero: m=audio 0 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 Do you ever see "Could not allocate new ports" in the log (media level, log level 1)? It seems that the PBX has a problem allocating new ports. It does not neem to be a general OS config problem, because other calls do get ports. What is your RTP port range that you have set on the PBX? Maybe you picked a very narrow range and becomes kind of random if the PBX can grab a new port or not. Quote Link to comment Share on other sites More sharing options...
SFX Group Posted April 22, 2012 Author Report Share Posted April 22, 2012 Hi, thanks for the port range issue, in another thread i had a probem with the HUNT GROUP which was the same problem here (HUNT GROUP problem), however it was said it appears to be RTP port problem. I extended the range (was 10001-10005, now 10001-10020), added them to the WIndows firewall and restarted the SNOM service, this seems to have fixed the issue. This could have been a nightmare, i have extend more ports..When i move this to Ubuntu or server 2008R2 it will be easier to manage (from a firewall point of view). I will post back if i see other issues. The phone is almost deployed now it tested ok. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 22, 2012 Report Share Posted April 22, 2012 I extended the range (was 10001-10005, now 10001-10020), added them to the WIndows firewall and restarted the SNOM service, this seems to have fixed the issue. This is still very tight. Keep in mind that every call has several legs and each call leg occupies 2 ports (RTP and RTCP). Because 10001 is a odd port, it is not available, the same for 10020 (because 10021 is not available). So you have essentially 10002..10019, which is 18 ports, 9 legs, equal to 4 x 2-legged calls. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.