Hunt Group Night Service Forwarding CLI Issue 2

[CMUK]

Hi Guys

Feel this should be fairly basic question, my customer puts his hunt group into night service when leaving the office, night service is set to go to his mobile, however it is sending the main CLI (this is defined under SIP tab in the group) if I remove I just get Private Number,
I have changed pretty much every setting I can see on the SIP Trunk such as the Forwarding/Twinning options, has anyone had this issue before?
It is IPO V11.1.23 and voiceflex sip trunks.
It works fine if I put the mobile directly into the ICR table as a destination.

Thanks



Calum M
ACSS

 

[IPid10t]

in the SIP Trunk>Call Details, SIP URI do you have your Forwarding/Twinning tab set to Original Caller?

 

[CMUK]

Yep got them set to Original Caller still no joy

Calum M
ACSS

 

[Westi]

trace the SIP call with Monitor and see if maybe the provider is not sending it even though your call sends the correct number.


Joe
FHandw, ACSS, ACIS

https://www.millsidetc.com/

 

[budbyrd]

I would check with your carrier. Some don't allow what can be considered 'spoofing' of the caller ID and only allow you to send numbers that are assigned to you account.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'

 

[CMUK]

on the trace it's sending huntgroupno@sipcarrier , I know thats because I haven't populated the SIP tab but I don't want to send out that number either.

The carrier seems to let me spoof the numbers fine it's just doing it through the hunt group divert that is the problem

Calum M
ACSS

 

[Westi]

If you send HG extension number then the carrier may replace that.
If it is the HG DID number then it should work except if there is a PAI requirement and they expect you to send your main number and then the caller ID to send as PAI

Joe
FHandw, ACSS, ACIS

https://www.millsidetc.com/

 

[CMUK]

I've got the DDI sending out but still no joy with the callers id

Calum M
ACSS

 

[Westi]

Maybe go to the provider and ask them what they see.

That seems the next step, if the provider is not one of those "we don't help you but you send something wrong" ones.
Had one of those and convinced the customer to change providers and all worked

Joe
FHandw, ACSS, ACIS

https://www.millsidetc.com/

 

[CMUK]

Okay sorted now....changed shortcodes about to NSSi , I thought that was more an ISDN thing but it fixed my issue!

Calum M
ACSS

 

[Westi]

Nice one CMUK
have some pink for posting the solution

Joe
FHandw, ACSS, ACIS

 

[Fr0gg3r - MaartenS]

I just had a ticket open for +3 months open at Avaya for this issue.

This is something that changed between R10 and R11.

In R10 you could do a inbound call from party A > huntgroup > user unconditional forward to external party B.
The external party B would then see the number of part A . (if all your settings are correct and in line with your SIP provider)

We upgraded a customer to R11. R11 has the renewed sip uri configuration window where you can select the Forwarding/Twinning URI = Original caller.
Which should display party A when a unc.forwarding/twinning call is placed.
This still works for scenario: party A inbound > user unc. foward to external party B. Part B sees number of Party A.
Using the following settings:

The Forwarding/Twinning settings set to original caller will 'overrule the 'use internal data' settings.

-> but the 'overruling of the 'use internal data' does not happen in the following scenario: inbound call from party A > huntgroup > user unconditional forward to external party B.
In R11 the configuration in the SIP URI for Forwarding/Twinning calls does not apply for this kind of callflow. Which is very strange because this callflow scenarion used to work just fine in R10.

After a very long ticket at Avaya the statement was:
- you cannot compare R10 with R11, they are different versions ( I obviously absolutely did not agree to their statement..)
- The fact that this is not working is not a bug but it just works as designed. (yeah ...)
- This is an added enhancement of the system. (also I do not agree.)

So for me this is still a bug, for Avaya it is not, so they will not fix it.

But there is a workaround.
When you want party A's clip to appear a the external destination phone follow this:
- add a system shortcode: 11N / Dial / 11N / ARS 50
- in ARS add a line for 11N / N / group id 11
- in your siptrunk config add a new URI groupid 11
- configure this URI as follows:

- For the user that is configured to do the unconditional forward: add the 'destination number' to the unc. fwd settings with prefix 11

This fixes the huntgroup unc.fwd issue.


I just gave up in trying to convince them of accepting it as a bug.

 

[sizbut]

Looking at how close your workaround is to the default settings of R11, I have to suspect that the changes they made fixed more "I can't get this working/I think this is a bug" issues for them than it caused for others.

[The Diversion header is also relatively new in SIP history terms (2010). The History-Info header was the one originally specified in the standards to carry routing extra information on forwarded calls, but it was Cisco I think who came along with the Diversion header and eventually bulldozed it from a non-standard header to being part of the SIP standards. So despite the passing of a decade, there may still be cases where the SIP provider won't recognise it.]

Stuck in a never ending cycle of file copying.