PBXes (http://www1.pbxes.com/forum/index.php)
- English (http://www1.pbxes.com/forum/board.php?boardid=16)
-- Bugs (http://www1.pbxes.com/forum/board.php?boardid=24)
--- RE: bug outside incoming calls (http://www1.pbxes.com/forum/threadid.php?threadid=1312986821)

Posted by mr5858 on 10.08.2011 at 16:33:

bug outside incoming calls

Hi there,

I cannot receive incoming calls from Viatalk.com to my extension mr5858-505@pbxes.org. I called them and they said they are getting from your server "address not found".

I was able to forward calls to my extension using ipkall.com so I know everything is setup correctly.

Please advice, Thanks

Posted by Diafora on 15.08.2011 at 00:14:

RE: bug outside incoming calls

Hey there,

The construct [mr5858-505@pbxes.org] is not an extension but a SIP URI. The 505 might be an extension in the mr5858 account of PBXes, but you can only verify if it is or not.

In principle, if you intend to send calls via SIP URIs towards PBXes, I advise you to stop using extension based URIs and start using arbitrary URIs which will not conflict with native extension URIs.

For example by using mr5858-bnxnm73sfgh@pbxes.org we both know that unless a matching Inbound Route is defined on your PBXes account, to allow these calls to end up somewhere inside your PBXes account, all inbound calls will fail with "Address not found" or "Address does not exist". So setup a matching Inbound Route mr5858-bnxnm73sfgh and send the calls to a real PBXes extension, a Ring Group or any other real PBXes destination.

Using arbitrary Inbound Routes to accept calls form SIP URIs has a few distinct advantages:

• It does not require creating an unnecessary Extension or Trunk, just to use its' URI.
• It allows you to give a meaningful description to the first part of the URI after the mr5858- So the URI could be mr5858-NiceName@pbxes.org
• It allows you to route calls to any valid PBXes' destination, not just the extension of that URI.
• It helps avoid routing conflicts, since it's arbitrary by definition, and should not exist anywhere else in your PBXes account.

Use this method and all ambiguity and unpredictability in routing inbound calls via SIP URIs should go away.

Posted by mr5858 on 15.08.2011 at 03:08:

RE: bug outside incoming calls

Hi Diafora,

Thanks very much for the advice. I did create a incoming route called mr5858-viatalk which point to the extension where I want to receive the calls but the behaviour is still the same, meaning, everything works like a charm when I call from ipkall.com and when I call from my trunk provider Viatalk I always get the "user not found" like message.

I remember reading one of the post with a similar problem with another DID Provider and it was regarding using the "invite" field instead of the "to" field.

This is what I got from Viatalk's technical support:

We are properly sending the call to your SIP address. Here is a capture of the call:

0.000000 -> SIP/SDP Request: INVITE sip:mr5858-103@pbxes.org, with session description
0.112550 -> SIP Status: 404 Not Found
0.112649 -> SIP Request: ACK sip:mr5858-103@pbxes.org

As you can see, the host, pbxes.org ( is replying with a 404 Not Found message indicating that it cannot find the extension mr5858-103. If you have any other questions, let us know. Thank you.

Eric Iversen
Systems Engineer

Please Advice how we get out of this catch 22.


Posted by Diafora on 20.08.2011 at 09:05:

RE: bug outside incoming calls

I am not sure what the issue is with this particular trunk, and since I haven't used ViaTalk as an ITSP yet, I cannot be certain where the issue lies. It's also unclear to me how using ipkall.com is related since chances are, their SIP Proxy is different that ViaTalk's.

The trace ViaTalk's techs provided you, is when their SIP Proxy sent an Invite to sip:mr5858-103@pbxes.org, which based on our previous discussion is not the most appropriate SIP URI to use. Ask them to send you a trace when their SIP Proxy sends the Invite to sip: mr5858-viatalk@pbxes.org, and there is a matching Inbound Route setup in your PBXes account.

Whether this issue is related to using the "Invite" field instead of the "To" field, is almost impossible to determine without looking at a SIP trace. I see two options for you to proceed, which require you to open a support case:

• Send us your ViaTalk's account credentials, so we can set them up on a test PBXes account, and work with you for test calls as well as to communicate with ViaTalk's techs. Once we determine the proper provisioning for the ViaTalk trunk, we will let you know how to set it up on your PBXes account.
• Send us your PBXes password, so we can test the trunk setup directly from your PBXes account. We might have to test the ViaTalk trunk on another PBXes account as well, just to ensure it's not a PBXes' account issue.

Let us know how you wish to proceed.

Powered by: Burning Board Lite 1.0.2 © 2001-2004 WoltLab GmbH
English translation by Satelk