Withheld CLI calls do not traverse SIP trunk

[DannyCodling]

Hi,

We have an IP Office 500 v1 which has a local SIP trunk to a call centre solution.

With the Avaya running v5 firmware, everything worked OK. We upgraded to v7 firmware and noticed that any callers who had a withheld or unavailable CLI had their calls immediately dropped.

The call centre solution is via a company who are not on the Dev connect programme and so it's pretty much shut door as far as Avaya are concerned.

The problem is that using wire shark, I don't see any network traffic coming from the IP Office to the call centre software were withheld calls are concerned - so I believe at this point that regardless of the solution at the end of the SIP trunk, the call would not be presented.

A work around is to pass withheld calls via voicemail pro and force a CLI before handing back to the SIP trunk.

Has anyone seen this issue before? Does the IP Office have a bug in v7?

Thanks in advance

Danny

 

[kholladay]

Not a lot of detail here but I'll give it my best shot.

To start, yes IP Office "have a bug in v7", and in v6.1 and v6.0 and v5 and every other version ever released or to be released. Don't think I've seen a piece of software or hardware appliance out there including the stereo in my 2008 Jeep and my DirecTV receiver that doesn't have a "bug". But does it have a bug that is specific to your situation remains to be seen.

It should be noted that SIP trunks in v5 are configured differently than in v7 and if you've just done a simple upgrade without taking that into consideration you may run into some difficulties. One of the big differences is in the use of p-Asserted-ID, which among other things is used for anonymous calling.

To start, is the SIP trunk between the CO/Provider and the IP Office, between the IP Office and the call center server or both?

You need to start by looking at the Monitor trace to see what happens to the call when it is received and processed. Start by following this guide and posting the results:

http://www.ipofficehelp.com/HOWTO_ConfigureMonitorComprehensive.aspx#SIPTroubleshoot

Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[DannyCodling]

Thanks Kyle,

I'm not sure what p-Asset-ID is - but it sure sounds like it's something that could be causing this issue.

The SIP trunk is between the IP Office and the call center software (it uses the Dialogic HMP 3.0 software component). We have an incoming call route that forwards the incoming call via a short code that is configured to forwards the call to the SIP trunk "1234@172.20.120.45"

I'll look at the how to guide you kindly posted and come back to you.

Thanks for your assistance.

Danny

 

[DannyCodling]

Hi Kyle,

Basically I called a test DDI (671592) from my mobile, placing 141 in front of the call to withhold my number. The IP Office has an ICR pointing 671592 to a destination of 8002. 8002 is a shortcode which points to "1234@172.20.120.45" via the SIP trunk (line 17).

All I heard from my mobile was a single beep, as the call was immediately disconnected. There were no rining or busy tones.

Thanks again,

Danny

Start of Log ********
UNICODE-UTF8
eng
1193057351mS R2DSP: PRIU DSP 1: read tone, port 0, channel 11, tone '1'
1193058143mS RES: Tue 17/1/2012 14:06:28 FreeMem=50050384(1) CMMsg=13 (13) Buff=5200 875 1000 7170 18 Links=17126
1193058144mS RES2: IP 500 7.0(27) Tasks=44 RTEngine=0 CMRTEngine=0 ExRTEngine=0 Timer=305 Poll=0 Ready=0 CMReady=0 CMQueue=0 VPNNQueue=0 Monitor=3 SSA=0 CF=UMNT
1193058431mS H323Evt: Recv: RegistrationRequest 172.26.120.210; Endpoints registered: 218; Endpoints in registration: 0
1193058532mS H323Evt: Recv: RegistrationRequest 172.26.120.133; Endpoints registered: 218; Endpoints in registration: 0
1193059991mS H323Evt: Recv: RegistrationRequest 172.26.120.203; Endpoints registered: 218; Endpoints in registration: 0
1193060099mS H323Evt: Recv: RegistrationRequest 172.26.120.222; Endpoints registered: 218; Endpoints in registration: 0
1193061322mS ISDNL3Evt: v=1 stacknum=1 State, new=Present, old=NullState id=12
1193061325mS PRN: Q931Trunk: Found QBChannel to match 0.12 --> 1.13
1193061326mS CMCallEvt: 0.173517.0 -1 BaseEP: NEW CMEndpoint f439e510 TOTAL NOW=63 CALL_LIST=31
1193061326mS CMCallEvt: CREATE CALL:53975 (f46bbc60)
1193061327mS CMCallEvt: 0.173518.0 -1 BaseEP: NEW CMEndpoint f4b320b4 TOTAL NOW=64 CALL_LIST=31
1193061329mS CMCallEvt: 1.12.1 53975 Q931 Trunk:1 CHAN=12: StateChange: END=A CMCSIdle->CMCSDialInitiated
1193061330mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: LOOKUP CALL ROUTE: type=0 called_party=671592 sub= calling= dir=in complete=1 ses=0
1193061330mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: SET BESTMATCH: length 0 vs -1 match= dest=8000
1193061331mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: SET BESTMATCH: length 6 vs 0 match=671592 dest=8002
1193061332mS CMCallEvt: Priority hike: call 53975 priority 0->1
1193061332mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: LOOKUP ICR: DDI= CGPN= (Destination 8002 ) => CDPN=8002
1193061332mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: ADD TARGET (N): number=8002 type=0 depth=1 nobar=1 setorig=1 ses=0
1193061333mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: SYS SC: 8002 4 sc=type=Dial code=8002, num=8002"@172.20.120.45" callinfop->sending_complete=1 secondary_dialtone=
1193061334mS CMARS: FindActiveARSByGroupID GroupID=40 - Not Found
1193061335mS CMTARGET: Group Id: 40 has NOT been found in Line: 5
1193061335mS CMTARGET: Group Id: 40 has NOT been found in Line: 13
1193061335mS Sip: SIPTrunks: Make Target voip, line group id is 40 and ip 172.20.120.45
1193061336mS CMMap: a=6.50 b=0.0 Mapper::AllocateCodec allocated CMRTVocoder resource busy 15, total 128
1193061336mS Sip: License, Valid 1, Available 60, Consumed 22
1193061337mS CMCallEvt: 0.173519.0 -1 BaseEP: NEW CMEndpoint f4495ab4 TOTAL NOW=65 CALL_LIST=32
1193061339mS CMTARGET: DIAL LINE: 53975 GROUP = 40 SUCCESS = f4495ab4
1193061339mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: INITIAL TARGETING SUCCEEDED
1193061339mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: GetNoAnswerTimer:15
1193061340mS CMCallEvt: 1.12.1 53975 Q931 Trunk:1 CHAN=12: StateChange: END=A CMCSDialInitiated->CMCSDialled
1193061341mS CMCallEvt: 0.173518.0 53975 TargetingEP: StateChange: END=B CMCSIdle->CMCSOffering
1193061342mS CMCallEvt: 17.173519.0 53975 SIPTrunk Endpoint: StateChange: END=T CMCSIdle->CMCSOffering
1193061344mS Sip: 17.173519.0 53975 SIPTrunk Endpoint(f4495ab4) received CMSetup
1193061345mS Sip: 17.173519.0 53975 SIPTrunk Endpoint(f4494950) CMSetup received, owner f4496fa8, dialog f4494950, dialling 8002@172.20.120.45
1193061345mS Sip: 17.173519.0 53975 SIPTrunk Endpoint(f4494950) Cannot assign a calling party, call won't proceed
1193061346mS CMCallEvt: 0.173518.0 53975 TargetingEP: RequestEnd 17.173519.0 53975 SIPTrunk Endpoint
1193061346mS CMTARGET: 1.12.1 53975 Q931 Trunk:1 CHAN=12: CancelTimer CMTCNoAnswerTimeout
1193061347mS CMCallEvt: 17.173519.0 53975 SIPTrunk Endpoint: StateChange: END=B CMCSOffering->CMCSCompleted
1193061348mS PRN: CDR - TCPSend maxqueuesize=1000 operational=1
1193061352mS CMCallEvt: 1.12.1 -1 Q931 Trunk:1 CHAN=12: StateChange: END=X CMCSDialled->CMCSCompleted
1193061353mS Sip: 17.173519.0 -1 SIPTrunk Endpoint(f4494950) Terminating dialog f4494950, state SIPDialog::INITIAL(0) for cause CMCauseNormal
1193061353mS CMCallEvt: 17.173519.0 -1 SIPTrunk Endpoint: StateChange: END=X CMCSCompleted->CMCSDelete
1193061354mS CMCallEvt: END CALL:53975 (f46bbc60)
1193061354mS Sip: ~SipTrunkEndpoint 17.173519.0 -1 SIPTrunk Endpoint
1193061355mS CMCallEvt: 17.173519.0 -1 BaseEP: DELETE CMEndpoint f4495ab4 TOTAL NOW=64 CALL_LIST=31
1193061356mS CMCallEvt: 0.173518.0 -1 TargetingEP: StateChange: END=X CMCSOffering->CMCSDelete
1193061356mS CMCallEvt: 0.173518.0 -1 BaseEP: DELETE CMEndpoint f4b320b4 TOTAL NOW=63 CALL_LIST=31
1193061381mS CMMap: a=6.50 b=0.0 Mapper::FreeCodec freed CMRTVocoder resource busy 14, total 128
1193061385mS ISDNL3Evt: v=1 stacknum=1 State, new=ICProceeding, old=Present id=12
1193061386mS ISDNL3Evt: v=1 stacknum=1 State, new=DiscReq, old=ICProceeding id=12
1193061406mS ISDNL3Evt: v=1 stacknum=1 State, new=NullState, old=DiscReq id=12
1193061407mS CMCallEvt: 1.12.1 -1 Q931 Trunk:1 CHAN=12: StateChange: END=X CMCSCompleted->CMCSDelete
1193061408mS CMTARGET: 1.12.1 -1 BaseEP: ~CMTargetHandler f464085c ep f439e510
1193061408mS CMCallEvt: 1.12.1 -1 BaseEP: DELETE CMEndpoint f439e510 TOTAL NOW=62 CALL_LIST=31
1193061477mS H323Evt: Recv: RegistrationRequest 172.26.120.191; Endpoints registered: 218; Endpoints in registration: 0
1193062719mS H323Evt: Recv: RegistrationRequest 172.26.120.90; Endpoints registered: 218; Endpoints in registration: 0
1193062739mS H323Evt: Recv: RegistrationRequest 172.26.120.63; Endpoints registered: 218; Endpoints in registration: 0
1193063020mS ISDNL3Evt: v=1 stacknum=1 State, new=NullState, old=ReleaseReq id=7
1193063390mS H323Evt: Recv: RegistrationRequest 172.26.120.96; Endpoints registered: 218; Endpoints in registration: 0
1193064004mS H323Evt: Recv: RegistrationRequest 172.26.120.72; Endpoints registered: 218; Endpoints in registration: 0
1193064449mS ISDNL3Evt: v=1 stacknum=1 State, new=ReleaseReq, old=Active id=27
1193064465mS ISDNL3Evt: v=1 stacknum=1 State, new=NullState, old=ReleaseReq id=27
1193064467mS CMCallEvt: 1.27.1 53968 Q931 Trunk:1 CHAN=4: StateChange: END=A CMCSConnected->CMCSCompleted
1193064468mS PRN: CDR - TCPSend maxqueuesize=1000 operational=1
1193064471mS CMCallEvt: 1.27.1 -1 Q931 Trunk:1 CHAN=4: StateChange: END=X CMCSCompleted->CMCSDelete
1193064472mS CMCallEvt: 0.173511.0 -1 RAS.0: StateChange: END=X CMCSConnected->CMCSCompleted
1193064477mS CMMap: a=21.11 b=0.0 T0
1193064478mS CMCallEvt: 0.173511.0 -1 RAS.-1: StateChange: END=X CMCSCompleted->CMCSDelete
1193064479mS CMCallEvt: 0.173511.0 -1 BaseEP: DELETE CMEndpoint f46d5e8c TOTAL NOW=61 CALL_LIST=30
1193064479mS CMCallEvt: END CALL:53968 (f4671d7c)
1193064481mS CMCallEvt: 1.27.1 -1 BaseEP: DELETE CMEndpoint f4683e2c TOTAL NOW=60 CALL_LIST=30
1193064486mS CMMap: PCG::UnmapBChan pcp[141]b1r0 cp_b f54a3e98 other_cp_b f5471cc8
1193064487mS CMMap: a=1.5 b=21.11 M0
1193064487mS CMMap: PCG::UnmapBChan pcp[188]b1r0 cp_b f5471cc8 other_cp_b 0
1193064643mS RES: Tue 17/1/2012 14:06:35 FreeMem=50071336(1) CMMsg=13 (13) Buff=5200 875 1000 7168 18 Links=17139
1193064644mS RES2: IP 500 7.0(27) Tasks=44 RTEngine=0 CMRTEngine=0 ExRTEngine=0 Timer=308 Poll=0 Ready=0 CMReady=0 CMQueue=0 VPNNQueue=0 Monitor=3 SSA=0 CF=UMNT
1193065066mS H323Evt: Recv: RegistrationRequest 172.26.120.217; Endpoints registered: 218; Endpoints in registration: 0
1193065072mS H323Evt: Recv: RegistrationRequest 172.26.120.159; Endpoints registered: 218; Endpoints in registration: 0
1193065220mS H323Evt: Recv: RegistrationRequest 172.26.120.211; Endpoints registered: 218; Endpoints in registration: 0
1193066250mS H323Evt: Recv: RegistrationRequest 172.26.120.40; Endpoints registered: 218; Endpoints in registration: 0
1193066599mS R2DSP: PRIU DSP 1: read tone, port 0, channel 2, tone 'C'

 

[amriddle01]

1193061345mS Sip: 17.173519.0 53975 SIPTrunk Endpoint(f4494950) Cannot assign a calling party, call won't proceed

Needs to send some form of caller ID

http://www.ipoffice.tel

 

[DannyCodling]

As Kyle says, it must be something new to v7. Everything was working fine before the upgrade. I checked the config and literally nothing had changed.

I'd assume lots of people would have seen this - whilst preying that surely we weren't the first :-( Our call centre was missing hundreds of a calls per day.

 

[kholladay]

On your SIP Line>SIP URI under the PAI drop down does it say None? If not change it and see what happens.

Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[DannyCodling]

It does say none.

I'll look at changing to each of the options - though I'll need to reboot the system so have to wait until after hours before I make the change.

I'll update this thread once I've tested.

Thanks again,

Danny

 

[amriddle01]

Just change and them and force it to do a merge, it still works even though it complains, works on 99% of SIP changes

http://www.ipoffice.tel

 

[amriddle01]

Just change them*

http://www.ipoffice.tel

 

[DannyCodling]

....is this likely to affect calls?

I dont know what the PAI settings are.

....and I'm a chicken

 

[kholladay]

My F1 key tells me this

PAI: Default = None. Software level = 6.1
You can enable P-Asserted-Identity (PAI) headers to assert the identity of users in outgoing SIP requests or response messages. Use this setting to select the source of the user identity information or enter a value manually. The selectable options are:

· None
When selected, the P-Preferred-Identity header is used instead of the P-Asserted-Identity, in order to ensure compatibility with legacy networks.

· Use Authentication Name: Software level = 4.0 to 5.0.
Use the appropriate Authentication Name on the SIP Line tab as indicated by the Registration setting below.

· Use Credentials User Name: Software level = 6.0+.
Use the User Name from the SIP Credentials entry used for the call.

· Use Internal Data
Use the SIP Name value from the User | SIP tab of the user making the call. IP Office 6.0: The system can also use SIP URI information configured for a hunt group (Hunt Group | SIP) or for the voicemail (System | Voicemail).


Kyle Holladay / IPOfficeHelp.com
ACSS/ACIS/APSS Avaya SME Communications
APDS Avaya Data
MCP/MCTS Exchange 2007/2010
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[DannyCodling]

I've changed the value of PAI to each of the settings available - but it didn't make any difference. That said I hope it wasn't the 1% of SIP changes that really did require a restart!

Might sound obvious, but could the option (in conjunction with PAI settings) for 'Send Caller ID' on the main SIP tab be the problem? It's currently set to none and the help guide refers to mobile twinning.

Regards,

Danny