gifti Posted March 4, 2013 Report Share Posted March 4, 2013 Hi all, following configuration for incoming calls: Patton Gateway => snomONE 5.0.4 => hunt-group with 4 members. When a call comes in and is immediately hung up, then the hunt-group members continue to ring after the CANCEL event. Normal callflow without issue: cancel_normal.txt 192.168.0.220(Patton) 192.168.0.200(snomONE) | | 1: |U------------INVITE----------->| 2: |<------100 Trying/INVITE------U| 3: |<------180 Ringing/INVITE-----U| 4: |U------------CANCEL----------->| 5: |<--------200 Ok/CANCEL--------U| 6: |<-487 Request Terminated/INVI-U| 7: |U-------------ACK------------->| Call is still disconnected on the gateway, but hunt-group members continue to ring: cancel_zu_frueh.txt 192.168.0.220(Patton) 192.168.0.200(snomONE) | | 1: |U------------INVITE----------->| 2: |<------100 Trying/INVITE------U| 3: |U------------CANCEL----------->| 4: |<------100 Trying/CANCEL------U| 5: |<--------200 Ok/CANCEL--------U| 6: |<-487 Request Terminated/INVI-U| 7: |U-------------ACK------------->| The only way to stop ringing is push the X-Button on every SNOM370 phone . regards Gifti Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 4, 2013 Report Share Posted March 4, 2013 The SIP call flow between Patton and the PBX looks okay. The question is how the call flow between the phones and the PBX looks like. Quote Link to comment Share on other sites More sharing options...
Vodia support Posted March 4, 2013 Report Share Posted March 4, 2013 We have tested your scenario with the 5.05 and it works fine. Stage 1 we have added 1 extension Stage 2 we have 2 extension Stage 3 we have 3 extension Final stage goes to VM On stage 3 I have abruptly hung the phone on my cell and the phones stop ringing. My suggestion is to provide us with a sip trace from the pbx or upgrade to the latest build. http://wiki.snomone.com/index.php?title=Release_5.0 Quote Link to comment Share on other sites More sharing options...
gifti Posted March 5, 2013 Author Report Share Posted March 5, 2013 We have tested your scenario with the 5.05 and it works fine. Stage 1 we have added 1 extension Stage 2 we have 2 extension Stage 3 we have 3 extension Final stage goes to VM On stage 3 I have abruptly hung the phone on my cell and the phones stop ringing. My suggestion is to provide us with a sip trace from the pbx or upgrade to the latest build. http://wiki.snomone....tle=Release_5.0 Thank you for your quick reponse ! - latest build 5.0.5 is installed ... problem still exists. - the point is, that only when the call ist hung up immediately (milliseconds) after dialing, the issue happens - I dial from outside, wait half a second and put the phone down - the snomONE get's the ringing message a bit later and the the HG stage one is ringing - there is no matter how much stages you use - the first stage continues ringing, whether it's one phone or more phones in the stage - there is no active call on the patton, it's a ghost ringing ... - when I wait a second or more and put the phone down ... everything works fine - the HG is ringing and stops ringing immediately after hang up - sip trace will follow regards gifti Quote Link to comment Share on other sites More sharing options...
gifti Posted March 5, 2013 Author Report Share Posted March 5, 2013 I generated two test scenarios without TLS connection between pbx and the phones. 192.168.0.220 = Patton 192.168.0.200 = snomONE 5.0.5 192.168.0.206,207 and 214 = snom370-SIP 8.7.3.19 in huntgoup stage one normal cancel message after 5 seconds ringing(between line 9 and 45): trace_normal.pdf cancel_normal_cut.txt cancel after 20 milliseconds ringing (between line 9 and 10) with ghost ringing on all stage one extensions : trace_ghost_ringing.pdf cancel_ghost_ringing_cut.txt Quote Link to comment Share on other sites More sharing options...
Steve B Posted March 5, 2013 Report Share Posted March 5, 2013 I generated two test scenarios without TCP connection between pbx and the phones. 192.168.0.220 = Patton 192.168.0.200 = snomONE 5.0.5 192.168.0.206,207 and 214 = snom370-SIP 8.7.3.19 in huntgoup stage one normal cancel message after 5 seconds ringing(between line 9 and 45): trace_normal.pdf cancel_normal_cut.txt cancel after 20 milliseconds ringing (between line 9 and 10) with ghost ringing on all stage one extensions : trace_ghost_ringing.pdf cancel_ghost_ringing_cut.txt I had this problem once when I was using UDP and a snom m9. When I changed to TCP/TLS it went away. This may not be your solution but I am just throwing out my experience. Quote Link to comment Share on other sites More sharing options...
gifti Posted March 5, 2013 Author Report Share Posted March 5, 2013 I had this problem once when I was using UDP and a snom m9. When I changed to TCP/TLS it went away. This may not be your solution but I am just throwing out my experience. I've deactivated TLS to create a readable SIP Logfile. In my opinion, the transport layer doesn't matter ... Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 5, 2013 Report Share Posted March 5, 2013 The madness is that according to the SIP standard, the one who sent an INVITE cannot cancel the request before a response have arrived. That makes the whole procedure difficult, and it is even difficult to say which device is buggy. In an extreme case, the phone does not respond for an hour and then the PBX is supposed to send the CANCEL. You can imagine what that means for keeping the memory clean from garbage. I would definitively use TLS instead of UDP, not only because of this. The next problem that you will be facing with UDP is fragmentation, not to mention eavesdropping and ALG messing with the packets. If HTTP would have used UDP, nobody would talk about the world wide web today anymore. Quote Link to comment Share on other sites More sharing options...
Vodia support Posted March 5, 2013 Report Share Posted March 5, 2013 I've deactivated TLS to create a readable SIP Logfile. In my opinion, the transport layer doesn't matter ... very difficult to recreate the 20 milliseconds test here . On the ghost calls, it does show that the pbx never sends an immediate cancel to the other parties. Couple things you can try is updating the phones to 8.4.35 and change the transport to the phone to TCP if you haven't already. Quote Link to comment Share on other sites More sharing options...
gifti Posted March 6, 2013 Author Report Share Posted March 6, 2013 Upgrading 8.4.35? I use the latest release 8.7.3.19. I've change the transport layer to TCP and then back to TLS. Problem persists. No, it is the evil pbx . If you take a look at the attachment trace_ghost_ringing_com.pdf 1.144269 => INVITE 5608 was sended before the request was terminated 1.425376 => snomONE sends a CANCEL ... the member of the huntgroup stops ringing but the other HG members 1.424504 => INVITE 10376 was sended after the request was terminated 1.424885 => INVITE 30970 was sended after the request was terminated ... => snomONE sends no CANCEL ... phone rings and rings I would suggest two Solutions: snomONE stops sending INVITEs to huntgroup members when a 487 Request Terminated is coming in (if the INVITE process is not yet complete) snomONE recognizes all INVITE messages after the "487 Request Terminated" and subsequently sends the CANCEL messages Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 7, 2013 Report Share Posted March 7, 2013 We need to set up a test for that. It is easy to reproduce and then it should also be easy to fix that. I suspect this is the side effect of a fix that we did for phones that loose registration while the hunt group is ringing. Quote Link to comment Share on other sites More sharing options...
gifti Posted April 17, 2013 Author Report Share Posted April 17, 2013 After upate to 5.0.8 the problem is gone ! 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.