Call Waiting Indicator Off but Still get a beep with second incoming call

[Wim van Ommen]

I have set the Call Waiting Indicator to Off in advanced_audio.htm.

I still get a beep with second incoming call, any ideas on getting this to work.

 

The phones are connected to pbxnsip and I'm using 7.1.33, but it was the same with 7.1.30.

 

The problem occurs on both the 360 and 320.

[sipnpbx]

I just tested it and it worked perfectly for me. If its set to off then the pbx gives a busy message instead of doing call waiting (where you hear the knocking). First, are you changing the setting on the phone web page or are you sending it this setting through provisioning? If its the second case then please change it on the phone itself first and press save then test it again. Also are you talking about connected state OR when the phone is ringing and another call comes in.

[Wim van Ommen]

I am talking about connected state, what happens is that I get 1 short beep when another call comes in.

[Wim van Ommen]

I've tested a little further, the issues is not really a beep, but something that sounds like a small drop in the sound when another call comes in.

 

Other SIP phones like the Siemens DECT/IP don't have this, so it seems a SNOM pbxnsip thing.

 

Any ideas on solving this issue?

[Vodia PBX]

I've tested a little further, the issues is not really a beep, but something that sounds like a small drop in the sound when another call comes in.

 

Other SIP phones like the Siemens DECT/IP don't have this, so it seems a SNOM pbxnsip thing.

 

We don't want to start mixing the PBX audio in the case of a call waiting, this is (a) pretty complicated and ( the SIP model is that is the job of the SIP phone. I guess snom needs to fix this.

[sipnpbx]

I've tested a little further, the issues is not really a beep, but something that sounds like a small drop in the sound when another call comes in.

 

Other SIP phones like the Siemens DECT/IP don't have this, so it seems a SNOM pbxnsip thing.

 

Any ideas on solving this issue?

[sipnpbx]

Can you please make a pcap trace and attach it. Please make a clean one which captures the SIP traffic and the RTP traffic. Its very strange because with call waiting off the phone simply declines the second call and the other side simply gets a busy tone or message, And that's what we see here. That's a pcap trace will be really helpful here.

[Wim van Ommen]

Can you please make a pcap trace and attach it. Please make a clean one which captures the SIP traffic and the RTP traffic.

I will try to make this on monday or tuesday, I have some other questions about you test though, and some extra info below you remark.

 

Its very strange because with call waiting off the phone simply declines the second call and the other side simply gets a busy tone or message, And that's what we see here. That's a pcap trace will be really helpful here.

 

Did you try this with a hunt/agent group?

 

Other thing is that it seems to only happen on the local network (so it looks like a broadcast thing), because the phone I have connected via a VPN does not show this behavior.

[Wim van Ommen]

I've finally managed to make a trace, I've attache it.

It's a Wireshark file, the problem start when 331 calls (Which you can see because there is a sip message from the agent group to my snom phone).

pbnsip_teles_snom_360.zip

[Vodia PBX]

I've finally managed to make a trace, I've attache it.

It's a Wireshark file, the problem start when 331 calls (Which you can see because there is a sip message from the agent group to my snom phone).

pbnsip_teles_snom_360.zip

 

Oh yes, there is really a crazy difference after about 10 seconds (packet #848). Is that the time when the PBX sends out the second call? In the embedded world, it is a little bit tricky to deal with the sudden demand for CPU. We tried to do a workaround in 3.0 (CS410), if feedback from there is okay we can port it back to 2.1 and then make another build for the PPC appliance.

[Wim van Ommen]

Does the workaround work?

Any idea on when a backport would be available?

[Vodia PBX]

Does the workaround work?

Any idea on when a backport would be available?

 

So far the workaround is to stay away from TLS and use UDP or TCP instead. We have a new toolchain for the CS410 that should make the PBX respect the real time scheduler the right way, but we need to polish that a little bit before we can release it. That will be definitevely much better than a backport, plus the backport will loose the system management web pages that we introduced in 3.0.

[Wim van Ommen]

Just to make sure we are talking about the same kind of issues here:

The software is running on a Teles Box, we are not using TLS and are using udp, the phone we use are Snom 320/360.

The main issue is that when a second call comes in the processor load briefly goes to a 100% and at that time the audio drops real shortly.

Immediately after that the load becomes normal and the audio is flowing again.

[Vodia PBX]

Just to make sure we are talking about the same kind of issues here:

The software is running on a Teles Box, we are not using TLS and are using udp, the phone we use are Snom 320/360.

The main issue is that when a second call comes in the processor load briefly goes to a 100% and at that time the audio drops real shortly.

Immediately after that the load becomes normal and the audio is flowing again.

 

Hmm. Hmm. Hmm. But you do see "Set scheduling priority to ..." on log level 5 after a start? That should tell the OS that RTP is more important than anything else. I remember there were some patches in the kernel with the scheduler. Maybe they had the side effect that the RR scheduling does not work properly any more. We have to check.