Avaya Core SIP and call forwarding to external number

[bankingguy]

Hi,

I have an Avaya SIP Stack setup (SMGR/SM/CM 8.1) with Audiocodes SBC with SIP trunk to our local Telco in Malaysia.

Call Scenario:
External Party calls Extension A, Extension A has a call-forward feature ON and forward that to Extension B - WORKS
External Party calls Extension A, Extension A has a call-forward feature ON and forward to mobile (EC500 not turned) - just simple call forward but NOT WORKING.

Any ideas? Well besides the COS, do we have to create any adaptation to perform digit / SIP message manipulation?

Any chance you can give me a sample configuration that works in your environment?

 

[phoneguy55]

what does traceSM show? If you are call forwarding off network back to the PSTN pay attention to the outbound caller ID. Some carries, will not allow you to send a call from a number that you do NOT own.

 

[bankingguy]

Thank you.

Yes, this is the one seems to be the culprit. I agree with you, and it is easy to do it if you are using ISDN PRI. But SIP trunk is a bit complex. do you have any adaptation configuration?

 

[kyle555]

You're not going to be able to do it on SM easily.

P83 for an idea of how to do it on Audiocodes. Although for "condition" it shouldn't be blank and should be something like "if a diversion header is present"

You might be able to do it with an adaptation on SM as long as "fromto" is false - that would change the origination stuff but not the from header - so just the P-Asserted-Identity.
p323

https://downloads.avaya.com/css/P8/documents/101058190

Say Extension A calls their cell. CM should send a call out with FROM and P-Asserted-Identity (PAI) = the number in the public unknown table of Extension A.
Extension A forwards Extension A to cell: CM would send FROM+PAI = the outside calling party and a diversion header of Extension A's public unknown entry
Extension A has EC500 to cell: same as previous case.

Carriers usually want PAI to = a DID on your SIP service. So the SIP manipulation rule becomes "if a diversion header exists, replace the PAI value with the value of that diversion header".

The FROM header is unchanged, so it'll still pass on the original calling party number on the mobile display of the EC500 user.

So could you do it on SM? Sure, but you'd have to turn on origination dial patterns and add each range of numbers your calls could come from and leave them unchanged. Then you'd have a catch-all for originating numbers that aren't part of your service - like your case - and replace PAI with your main DID or something. It's easier to do on the SBC.

 

[bankingguy]

Thanks Kyle. You got it working in Audiocodes?

 

[kyle555]

Never touched audiocodes SBCs. See if there's some interop note on devconnect for your carrier with an Avaya sbc.

If so, the Avaya manipulation is what you need to reproduce. Googling an audiocodes reference doc for that carrier for anything else - like maybe teams or something would show you how to make the audiocodes rule.

If you can traceSM Ext A calling the Cell vs the EC500, compare the p-asserted identities and what error code the carrier gave