Megapath Trunks

[Anonymous]

I see there is an issue listed in the software release notes relating to the forwarding of calls externally on Megapath trunks.  I have a customer who needs this exact application.  Is there a workaround or a fix that can used to correct this issue.  He uses it for the forwarding of calls to an emergency service line after hours for tenants in apartment buildings.  Any thoughts?

[jayh]

Did you try the workaround listed in the R10.9.4 release notes?

Inbound calls from Megapath (Broadsoft) SIP trunks fail to be delivered by FindMe-FollowMe to

external numbers. Calls roll to next Call Coverage item after being answered at the external number.

Workaround:

Enable Ringback Only and disable the Accept option in the FindMe-FollowMe

configuration for the call to external party to be successful.

[Anonymous]

These calls are being sent to external transfer from an auto attendant, not through find me follow me.  Does the known issue not apply to this?

[jayh]

Interesting.  Your initial post stated "after hours" so it didn't appear that an attendant was involved.  If this is indeed an after hours setup I would try the workaround suggested and see if it solves the problem.  Sometimes the release notes and bug reports don't address every scenario where the problem occurs.

Unattended off-site redirects to another number are generally considered a form of find-me-follow-me.

[Anonymous]

I am not sure how to apply the workaround i this situation. It is not

set though a user config, but in an auto-attendant to send the call to

an external number. I could send it to a virtual user, and have that

set for Find-me Follow-me, if you think that is a better method of

completing the transfer.

Andrew

[Anonymous]

Andrew,

If the issue you were referring to in your original post was the one that jayh cited, it should only apply to coverage for a user using FMFM.  Do you have issues with an Auto Attendant doing external transfers?

Thanks,

Matt

[Anonymous]

Yes, using the AA for external transfers. Currently i am getting it to

function by sending the calls out a SIP trunk from another provider.

Would like to stop using this method.

[Anonymous]

Can you set up a test for this on the Megapath SIP trunk so we can see exactly what is happening?  I would need to see the corresponding 7100 configuration along with the output of a debug sip stack messages and debug voice verbose both enabled at the same time while the issue is recreated.  You can submit those to the FTP server with the instructions below.  Also, let me know the last 5 digits of the number you were calling from for the test.

Open Internet Explorer web browser on their PC
Type the following URL:  ftp://ftp.adtran.com
Press the Alt key, click View, and then click Open FTP Site in Windows Explorer
Double-click the "Incoming" folder
Drag and drop files from PC into the Internet Explorer window

Reply to this post with the exact filenames used so we can retrieve the files

Thanks,
Matt

[Anonymous]

Are you sending the calling party number from the originating call when it forwards externally? I do not know the Megapath stance on that, but some service providers will screen calls based on the customers DID's and will not allow calls that appear to originate for a number that is not assigned to the trunk.

Have you contacted Megaqpath to see if they can provide any assistance in determining why the calls are being allowed?

[Anonymous]

Megapath states that they do support calls sending originating caller ID with diversion support. They do reject calls that come from "outside" the account. Apparently both ID's are sent with a fiversion header. I dont quite fully understand how this is set up. 

Andrew Trevarthen

Digital Matrix

[Anonymous]

andrewtre,

    I had problems with the Auto Attendant directing calls out as well, it looked like the system was registering it as a hairpin call.  So I created a virtual user and set up always call forward.  So that will at least get calls going out.  As for the Caller ID our after hours service uses the caller id to determine how to answer the phone so we have it out pulse our caller id number not the caller id of the caller.  So I would remove the diversion headers and call it good, let the answering service collect the callers number.

John Wable