Redirection Problems/Questions

[Tim]

We have several clients we are planning to move from the existing (*) servers to a hosted pbxnsip platform. They have been interested in using many of the redirection features that pbxnsip offers. In my testing of the redirection features, I have come across a couple of problems.

 

When filtering anonymous callers, if 'Pretend to be busy' is selected you get the same message as if 'Reject Call' is selected. Unless you setup a call forward on busy number, then it will complete to the CFB number. Is this the expected behavior?

 

If I call into the DID, and forking to my cell phone is enabled, it forks the call back to my cell phone. This would prevent a client that has no auto attendants from accessing their voicemail from their cell phones remotely. Is there a way to prevent the call from forking if the ANI == the Cell phone number field? I am not expecting the full DISA functionality that is provided when calling the AA, as long as the client can reach the VM greetomg so they can press '*' to access their voicemail remotely. In fact, that would be my preferred method of handling this call scenario. A call trap can be provided upon request.

 

Not really a redirection problem, but it is related to the Cell phone number field. I noticed on a hosted PBX system if I call the DID of an AA in another domain from my extension I still get the "Press 1... Press 2... Press 3..." options. Is this the expected behavior? I would have thought that it would only try to match cell phone numbers from extensions within the domain of the AA.

 

Finally, when using the 'Ask for name' announcement mode for anonymous calls, and having my cell phone forking set to 'Immediate,' I am getting 2 INVITEd calls for the call out to my cell phone. They are not duplicate or retried packets, as they have 2 different Call-ID's in the INVITEs. This second call is going directly to my cell phone provider's voicemail system because the first call setup attempt blocks the second incoming call. This is not happening when the forking delay interval is set to 1 second or more. This also does not happen when forking immediately for a non-anonymous call, I have only been able to recreate the problem when filtering anonymous calls and forking immediately to my cell phone. Earlier today I captured 2 calls to illustrate the problem, one set was to fork immediately and the other was set to fork after 1 second earlier. I have sanitized and attached the capture to this post.

 

Any help you can provide to sort out the 4 issues above would be greatly appreciated.

 

Tim Donahue

Sanitized_ngrep_capture.txt

[Vodia PBX]

When filtering anonymous callers, if 'Pretend to be busy' is selected you get the same message as if 'Reject Call' is selected. Unless you setup a call forward on busy number, then it will complete to the CFB number. Is this the expected behavior?

 

Yes, these two actions are quite similar. The difference is that the 'Pretend to be busy' sends a missed call and checks for redirects, while 'Reject Call' does not redirect the call (more rigorous). I would say the first one may redirect the call to an assistant for call screening, the second one does not accept anonymous at all.

 

If I call into the DID, and forking to my cell phone is enabled, it forks the call back to my cell phone. This would prevent a client that has no auto attendants from accessing their voicemail from their cell phones remotely. Is there a way to prevent the call from forking if the ANI == the Cell phone number field? I am not expecting the full DISA functionality that is provided when calling the AA, as long as the client can reach the VM greetomg so they can press '*' to access their voicemail remotely. In fact, that would be my preferred method of handling this call scenario. A call trap can be provided upon request.

 

I think we have to turn off cell phone forking if the call comes from the same cell phone. Will be in the next version.

 

Not really a redirection problem, but it is related to the Cell phone number field. I noticed on a hosted PBX system if I call the DID of an AA in another domain from my extension I still get the "Press 1... Press 2... Press 3..." options. Is this the expected behavior? I would have thought that it would only try to match cell phone numbers from extensions within the domain of the AA.

 

Oh yes, that is not good. It is not a secury problem as the caller still has to punch in the PIN, but must be corrected (next version will have it).

 

Finally, when using the 'Ask for name' announcement mode for anonymous calls, and having my cell phone forking set to 'Immediate,' I am getting 2 INVITEd calls for the call out to my cell phone. They are not duplicate or retried packets, as they have 2 different Call-ID's in the INVITEs. This second call is going directly to my cell phone provider's voicemail system because the first call setup attempt blocks the second incoming call. This is not happening when the forking delay interval is set to 1 second or more. This also does not happen when forking immediately for a non-anonymous call, I have only been able to recreate the problem when filtering anonymous calls and forking immediately to my cell phone. Earlier today I captured 2 calls to illustrate the problem, one set was to fork immediately and the other was set to fork after 1 second earlier. I have sanitized and attached the capture to this post.

 

Yea, in the case of the intercept, the PBX did set a timeout of 0 to call the cell phone in addition to calling it immediately. Will also be fixed in the next version.

[Tim]

Yes, these two actions are quite similar. The difference is that the 'Pretend to be busy' sends a missed call and checks for redirects, while 'Reject Call' does not redirect the call (more rigorous). I would say the first one may redirect the call to an assistant for call screening, the second one does not accept anonymous at all.

 

I think we have to turn off cell phone forking if the call comes from the same cell phone. Will be in the next version.

 

Oh yes, that is not good. It is not a secury problem as the caller still has to punch in the PIN, but must be corrected (next version will have it).

 

Yea, in the case of the intercept, the PBX did set a timeout of 0 to call the cell phone in addition to calling it immediately. Will also be fixed in the next version.

 

Great to hear we can get these cleaned up that quickly. Thanks for the help.

 

Tim