Version 4 audio issues

[jlumby]

I have a couple of customers that are long time PBXnSIP users. They were running fine in version 3. I upgraded them to version 4 to gain DoS protection. At that time, they started noticing that occasionally they would get calls with no audio. For the most part they wrote it off as someone hanging up on them. However they just discovered that it is happening every now and then with extension to extension calls. The extension to extension calls are not going through any kind of NAT, and their network topology has not changed since they were running V3 perfectly. One is running Cisco phones, and the other is running Aastra. The only thing that has changed is the PBX is now at version 4. To have this happening to 2 completely unrelated customers makes me suspect something in V4. Are there any changes in settings that V4 has that I should be aware of that might do this, or is anyone else experiencing this? It does not happen very often, only 1-2 calls out of every 500, so it is very difficult to replicate in order to capture while it is happening.

 

On a possibly unrelated note, I noticed that Version 4 generates a whole lot of emails that have the subject line of: User disconnects call. The body contains the line stating that "One side of the call between X and Y did not receive media for Z seconds and the other side of the call disconnected the call." The funny thing is I am sure that most of these are incorrect. The reason I know this is because I can generate it every time I page to a paging group where the only member is a cyberdata paging gateway (which paging by definition should have 1 way audio), or by faxing. The faxes always go through, however I believe the PBX stops getting traditional media, switches to T.38, and therefore thinks it is not getting media, when really all that happened is that it is getting T.38 instead of traditional audio.

 

Please let me know your experiences/ideas

[Vodia PBX]

I have a couple of customers that are long time PBXnSIP users. They were running fine in version 3. I upgraded them to version 4 to gain DoS protection. At that time, they started noticing that occasionally they would get calls with no audio. For the most part they wrote it off as someone hanging up on them. However they just discovered that it is happening every now and then with extension to extension calls. The extension to extension calls are not going through any kind of NAT, and their network topology has not changed since they were running V3 perfectly. One is running Cisco phones, and the other is running Aastra. The only thing that has changed is the PBX is now at version 4. To have this happening to 2 completely unrelated customers makes me suspect something in V4. Are there any changes in settings that V4 has that I should be aware of that might do this, or is anyone else experiencing this? It does not happen very often, only 1-2 calls out of every 500, so it is very difficult to replicate in order to capture while it is happening.

 

I see two possibilities for that. The first one is that the PBX changes the codec during the call setup. We introduced a flag calls "lock codec" later, make sure that it is turned on.

 

The other thing is the loopback calls. This continues to be a pain in the neck. SIP is very complicated when it comes to sending a request our and then it comes back to the system with all those tricky strict and loose routing and loop detection RFC... The easiest way to address this problem is to run it through another B2BUA, typically a PSTN gateway and implement the loop on the PSTN side.

 

On a possibly unrelated note, I noticed that Version 4 generates a whole lot of emails that have the subject line of: User disconnects call. The body contains the line stating that "One side of the call between X and Y did not receive media for Z seconds and the other side of the call disconnected the call." The funny thing is I am sure that most of these are incorrect. The reason I know this is because I can generate it every time I page to a paging group where the only member is a cyberdata paging gateway (which paging by definition should have 1 way audio), or by faxing. The faxes always go through, however I believe the PBX stops getting traditional media, switches to T.38, and therefore thinks it is not getting media, when really all that happened is that it is getting T.38 instead of traditional audio.

 

Yea, we decided to use email a lot more than before. Most of the emails are early warnings, e.g. for the case when the call gets disconnected while there is a one-way audio situation but not long enough for a PBX-initiated hangup. Typically, if both parties are real persons, one will look into the handset, say "heh?" and then hangup. We wanted to be able to capture these kind of problems as well. FAX is a situation like this, because T.38 is a very strange protocol with long periods of media flowing only into one direction (well, after all sendin ga page goes only into one direction).

 

A email rule in your email client might do the trick here to fish out the fax-related false alarms.

[polycom2080]

I see two possibilities for that. The first one is that the PBX changes the codec during the call setup. We introduced a flag calls "lock codec" later, make sure that it is turned on.

 

The other thing is the loopback calls. This continues to be a pain in the neck. SIP is very complicated when it comes to sending a request our and then it comes back to the system with all those tricky strict and loose routing and loop detection RFC... The easiest way to address this problem is to run it through another B2BUA, typically a PSTN gateway and implement the loop on the PSTN side.

 

 

 

Yea, we decided to use email a lot more than before. Most of the emails are early warnings, e.g. for the case when the call gets disconnected while there is a one-way audio situation but not long enough for a PBX-initiated hangup. Typically, if both parties are real persons, one will look into the handset, say "heh?" and then hangup. We wanted to be able to capture these kind of problems as well. FAX is a situation like this, because T.38 is a very strange protocol with long periods of media flowing only into one direction (well, after all sendin ga page goes only into one direction).

 

A email rule in your email client might do the trick here to fish out the fax-related false alarms.

 

we have been experiencing the same issue,

i would say 1 out of a 100 calls,

 

same issue only on v4. and above and on 3.4 we never had such issue