PBXes (http://www1.pbxes.com/forum/index.php)
- English (http://www1.pbxes.com/forum/board.php?boardid=16)
-- Providers (http://www1.pbxes.com/forum/board.php?boardid=22)
--- (http://www1.pbxes.com/forum/threadid.php?threadid=1687)

Call drops when answering

Hi

I have two trunks, each registered with Sipgate UK under different accounts. I.E, trunk A is registered to account A on sipgate.co.uk and trunk B is registered to account B on sipgate.co.uk.

When I receive a call on trunk A the call drops as soon as I answer. I've looked in the Wiki FAQs and found this reference. Item 10 in the FAQ.
"If you have such problems with incoming calls it is likely that a trunk was registered twice. Check if you have still registered to your SIP provider directly from a phone. Delete those! A reason can also be that a trunk has recently been renamed. In these cases it can be neccessary to wait up to a day to clear the registrations.

Another reason can be found in the advanced options "audio bypass" and "G.729 passthru". That's why they are disabled by default. Disable to find out whether one of your phones or providers don't support them. "

I have checked and I don't have a trunk registered twice.
I also haven't recently renamed a trunk.
I have audio bypass and G.729 passthru disabled.

What else could I check? Can anyone offer any suggestions as to what my problem may be.

I'm on the Frankfurt server if that makes any difference.

Thanks.

Don't know if the problem is having 2 accounts at sipgate.

If so try to delete 1 trunk and register only truk a. It can take up to 1 hour before registration of trunk b is disabled. so wait.

Have you setup an incoming route for this trunk ?

Since it is not clear from the description in your post, if the trunks work properly bt themselves, try the following procedure.

Delete all the Sipgate trunks from your PBXes account, and wait a little more than 1 hour. Delete the Inbound Routes for these trunks too.

Register an ATA or soft-phone using the credentials of one of the Sipgate trunks, and call its' associated DID. Can the call be completed properly? If it can, repeat the process with the other Sipgate account credentials.

Then, use the first account's credentials (which should not be registered on the ATA of soft-phone any longer) and create a trunk on your PBXes account, but not an Inbound route yet. Ensure the Inbound Calls are set to an already registered extension nearby.

Call the DID associated with the recently registered trunk, and verify if the call rings the default extension in Inbound Calls. Does the call drop as before?

Ok an update. I've had a chance to carry out the tests you suggested.

Registered with Sipgate account A using Xlite and calls were answered successfully.
Registered with Sipgate account B using Xlite and calls were answered successfully.
Created trunk A registered to Sipgate account A and calls were answered successfully.
Created trunk B registered to Sipgate account B and calls were answered successfully.

I then went onto setting up the inbound routes for the two trunks. Trunk A routes to extension A, trunk B routes to extention B.

Test calls: Trunk B answers successfully, Trunk A drops the call. I deleted the routes again and only created a route for trunk A. It answered the call successfully. I then deleted route for trunk A and created route for trunk B. Trunk B answers successfully. I then created the route for trunk A again and now that works too.

I don't know why that happened and why Trunk A was dropping the call but it's working for the moment so I'll monitor it and see how it goes.

Zitat:

Originally posted by Diafora Since it is not clear from the description in your post, if the trunks work properly bt themselves, try the following procedure. Delete all the Sipgate trunks from your PBXes account, and wait a little more than 1 hour. Delete the Inbound Routes for these trunks too. Register an ATA or soft-phone using the credentials of one of the Sipgate trunks, and call its' associated DID. Can the call be completed properly? If it can, repeat the process with the other Sipgate account credentials. Then, use the first account's credentials (which should not be registered on the ATA of soft-phone any longer) and create a trunk on your PBXes account, but not an Inbound route yet. Ensure the Inbound Calls are set to an already registered extension nearby. Call the DID associated with the recently registered trunk, and verify if the call rings the default extension in Inbound Calls. Does the call drop as before?

I have the same problem, and followed the above steps (deleted inbound trunk for 1+ hour), however I'm able to receive calls if they ring my internal extension, or use a soft phone.

I am not able to receive calls if they are delivered to my cell phone - my mobile rings for 1/2 a ring, and then immediately hangs up, the DID continues to ring, and a few second later my mobile rings again and the cycle repeats. I've tried ringing the mobile with different outbound VSP with the same results.

The trunk name is still "sipgate.de" in call monitor which is an old name that I used for the trunk, it did not update to the new name. What's really odd is I don't have the problem if I forward the sipgate line to another PSTN number - it's only my mobile phone, however the converse is not true, I'm able to hunt my other DIDs to my mobile.

Eg:
sipgate -> Sprint mobile: immediate disconnect
sipgate -> POTS line: works fine
IPkall/Callcentric DID -> Sprint mobile: works fine

I've left the trunk deleted for a day, and still have the same problem. Thoughts?

*update* So, I used to work for Sprint, and had an old coworker pull the logs from the switch that serves me in San Francisco, here's the message:

06/25/08 13:10:49 #
161845

22 REPT:TLDN TIMEOUT
ORIG_MSCID 0-3-4183
MDN 415948xxxx, MIN 415225xxxx, IMSI Not Active
TLDN 510459xxxx

"Temporary local directory numbers" used to transfer calls between physical switches (my number resides in SF, but I'm across the water in Oakland, so the call terminates in the San Francisco switch and is transfered via SS7 on an ATM circuit). So it appears as though something at the Sprint 5E doesn't like information in the call record that it's receiving from pbxes. I'll see if I can get a copy of the AMA to see if it helps. Is there anything in the pbxes call log that shows an error?