cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to conect In Bound calls

0 Kudos

Hi experts,

I'm setting up a pretty simple scenario for inbound calls in SAP CCtr 7.0.12.0. As detailed in the SAP documentation the current setup is as follow:

SIP Trunk configured (only one configured):

Switching Route (only one configured):



The customer gateway delivers the destination number as just the last 4 digits. Logs generated in CallDispatcher show the following:

caller number: 997780005

destination (CCtr queue): 5640

22:52:09.904 (09080/IpcWorker ) TRC> SipBridge> [DEV_XXXX_PSTN_Lima] CALL_COMING {52584F2E5EC1C54086665C0269428222} IP=;CALLER=997780005;CALLED=5640;phone-context=cdp.udp;CALL_ID=52584F2E5EC1C54086665C0269428222;PORT=0;SIP_CALL_ID=82e7478-a01640a-13c4-55013-1aae6d-6ff71a08-1aae6d;_EVT=CALL_COMING;_SEL=10.100.1.10; 22:52:09.905 (07920/evtThread ) TRC> Gateway fetched by selector gw=674B9FBC-A6D0-46B6-A1C7-2A781DE701EF sel=X.X.X.X:0 22:52:09.905 (07920/evtThread ) TRC> 5640;phone-context=cdp.udp matched pattern #* with value 9 22:52:09.905 (07920/evtThread ) TRC> INF> Created out context > Dest=58B9B8CA-7A9C-4C6B-8CC1-9F1EF0DFE3CD Sel=X.X.X.X ANum=997780005 BNum=5640;phone-context=cdp.udp 22:52:09.905 (07920/evtThread ) TRC> GW2GW routing disabled, rejecting incoming 22:52:09.905 (07920/evtThread ) TRC> SipBridge< [DEV_XXXX_PSTN_Lima] CALL_REJECT {52584F2E5EC1C54086665C0269428222} _CMD=CALL_REJECT;CALL_ID=52584F2E5EC1C54086665C0269428222;CAUSE=1;REASON=NOROUTE;

Looks like the CD it is not being able to solve the route which is basically a queue number within the system. Additionally outbound calls are working with no problems.

Please let me know what else could I check in order to solve this issue. Thanks in advance.

Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

Hi Jukka,

Finally I figure out how to solve it. The actual "number" delivered by SIP GW was "CALLED=5640;phone-context=cdp.udp" as we previously saw in logs:

16:26:38.821 (09080/IpcWorker ) TRC> SipBridge> [DEV_FERREYROS_PSTN_Lima] CALL_COMING {59E51D7D1DAA4147A66B979EFD1F14F0} IP=;CALLER=997780005;CALLED=5640;phone-context=cdp.udp;CALL_ID=59E51D7D1DAA4147A66B979EFD1F14F0;PORT=0;SIP_CALL_ID=7ee9d18-a01640a-13c4-55013-1584d-719426aa-1584d;_EVT=CALL_COMING;_SEL=X.X.X.X;


And with the Edit Incoming B Number(In Mask) = #### the last four digits were '.udp' as it was shown in the same logs:


16:26:38.821 (07920/evtThread ) TRC> INF> Created out context > Dest=58B9B8CA-7A9C-4C6B-8CC1-9F1EF0DFE3CD Sel=X.X.X.X ANum=997780005 BNum=.udp


So basically I had to use the Edit Incoming B Number(In Mask) = ####?????????????????????? in order to remove all the stuff after the number. I'm not pretty sure if there is a better configuration to solve it but with this one now is working properly.


Regards,

Emilio Lobos



Answers (3)

Answers (3)

lloyd_goveia
Active Participant
0 Kudos

Hi Emilio,

This is really good news and thank you for sharing the outcome with the community.

I have also created KBA 2688900 - Call Dispatcher cannot route inbound call to existing Queue in SAP Contact Center for other customers reference.

Kind regards,
Lloyd

0 Kudos

Hi Jukka,

Thanks for the advises.

Regarding to the topic, I've tried several options like use the #### config in the Trunk Edit Incoming B Number(In Mask) but it seems doesn't catch any digit as BNumber:

16:26:38.821 (09080/IpcWorker ) TRC> SipBridge> [DEV_FERREYROS_PSTN_Lima] CALL_COMING {59E51D7D1DAA4147A66B979EFD1F14F0} IP=;CALLER=997780005;CALLED=5640;phone-context=cdp.udp;CALL_ID=59E51D7D1DAA4147A66B979EFD1F14F0;PORT=0;SIP_CALL_ID=7ee9d18-a01640a-13c4-55013-1584d-719426aa-1584d;_EVT=CALL_COMING;_SEL=X.X.X.X;

16:26:38.821 (07920/evtThread ) TRC> Gateway fetched by selector gw=674B9FBC-A6D0-46B6-A1C7-2A781DE701EF sel=X.X.X.X:0 16:26:38.821 (07920/evtThread ) TRC> .udp matched pattern #* with value 9

16:26:38.821 (07920/evtThread ) TRC> INF> Created out context > Dest=58B9B8CA-7A9C-4C6B-8CC1-9F1EF0DFE3CD Sel=X.X.X.X ANum=997780005 BNum=.udp

16:26:38.821 (07920/evtThread ) TRC> GW2GW routing disabled, rejecting incoming

16:26:38.821 (07920/evtThread ) TRC> SipBridge< [DEV_FERREYROS_PSTN_Lima] CALL_REJECT {59E51D7D1DAA4147A66B979EFD1F14F0}

Also I've tried "hardcode" a specific internal number (in this case 5640) in Edit Incoming B Number(In Mask) and the call is properly routed to this internal number in CCtr.

Now I'm asking to the people in charge of the Gateway to change the settings and send to CCtr the full destionation number in order to test.

Thanks.

former_member202106
Contributor
0 Kudos

Did you got it working? The "GW2GW routing disabled, rejecting incoming" Message refers to situation where system is not configured to allow call routing from gateway to gateway, for example flow like PSTN <-> gateway1 <-> gateway2 <-> PSTN.

In other words system tries to push the call to PSTN and doesn't recognize it as internal number.

BR,
Jukka

0 Kudos

Hi Jukka,

Yes, the problem is clearly the Call Dispatcher or CEM are not determining properly this number as an internal number. I opened an incident with SAP so we are moving forward with this issue. I'll update this post as soon as we find out a solution.

Best regards,

Emilio Lobos

former_member202106
Contributor
0 Kudos

Hi Emilio,

As a starter you should check configuration at SC - Call Switching - Trunks - The trunk - Edit Incoming B number (In mask). In your case this should be #### (4 times #). As this seems to be DEV environment I recommend to do CD reset after changing the setting even thought this parameter is taken to running config on fly.

In general the recommendation is that phone gateway should send the full phone number to SAP CCtr and with mentioned setting you define how many digits are read as internal number. For example customer calls to +358 10 123 4567 (Finnish phone number) and if you have #### defined in the trunk settings then CCtr application searches for internal number "4567".

Also if the system is integrated to CRM then you would definitely need full number to identify the customer. Searching with only four digits will cause unwanted results.

BR,
Jukka

ps. SAP does not recommend to paste log prints to community as is. That is because those typically contain customer data. For example the part you pasted reveals that this is DEV environment, customer name and ip addresses. In other words quite powerful tools to start hacking. Please modify the posting accordingly.