Accepted Solutions
To me it sounds like you might have a call routing loop. Look at the data at hand in the CDR and in the configuration in CM to try to find what is causing the call to loop. One common cause of this can be that your gateway incoming CSS has access to routing for external calls, ie it sees partition(s) that holds route pattern(s) that sends the call back to the PSTN. As this would just result in the call being sent back to you again by the service provider you have a call routing loop. This very often occurs if the call is destined to a number that is not allocated in your CM and the gateway can send calls to the PSTN on the inbound CSS. In general the inbound CSS of gateways/trunks do not need to have visibility of partitions that grants access to egress call routing to the PSTN, it should only need to see partition(s) used for internal calls.
To me it sounds like you might have a call routing loop. Look at the data at hand in the CDR and in the configuration in CM to try to find what is causing the call to loop. One common cause of this can be that your gateway incoming CSS has access to routing for external calls, ie it sees partition(s) that holds route pattern(s) that sends the call back to the PSTN. As this would just result in the call being sent back to you again by the service provider you have a call routing loop. This very often occurs if the call is destined to a number that is not allocated in your CM and the gateway can send calls to the PSTN on the inbound CSS. In general the inbound CSS of gateways/trunks do not need to have visibility of partitions that grants access to egress call routing to the PSTN, it should only need to see partition(s) used for internal calls.
Not from what I know and may I ask what good would that do? Why would you want to do that as that’s like acting as an ostrich that thinks if you don’t see the problem, by sticking their head in the sand, there is no problem.
Even if you could turn off CDR creation for calls coming from/going to a SIP trunk you would still have the call loop and that is a bad thing. It’s better to fix your problem, then to try to hide it.
btw, yes our current sip trunks are configured with CSS "international"
check the attached pls.
From what I can tell there is nothing attached.
If you have your SIP trunk set to have access to international call routing that would likely be what is causing the call loop. Apart from causing a loop it also makes you susceptible for call fraud as a caller from external source can use your gateway to have a call extended back out to the PSTN. This is a very bad practice and should be changed at the soonest.
This morning the picture showed up. As it seems like you might be passing the calls onwards to something other than CM can you please provide a little bit of details on your intended call flow to make it clearer what you want to achieve? With the current information at hand it is virtually impossible to give you any quality advice as we do not know what your intent is with your setup.
Also please share the content of the CSS that you have set as the inbound on the trunk.
The inbound CSS is used for calls from the Highpath system. What I think that you’re describing with this part “we enabled the CSS inbound as international because we use the SEIMENS system to call to international destinations.” is that you send calls to the Highpath system for calls to international numbers. This has nothing to do with the inbound CSS on the SIP trunk.
Then later you state this “since I disabled the CSS and made is as internal, any user on the SEIMENS system lost the call permission to external destinations.”, to me this sounds like the call path would be the opposite as from what you first described. If you mean that calls from the Highpath system should be allowed to make calls to international numbers via the CM I would recommend you to use a separate partition for this that sends calls to only the entity that handles these calls so that they don’t loop back to the Highpath system. Then on the other hand it could as well be that your trying to explain that endpoints on the Highpath system sends calls destined for PSTN to CM and then you send it back to the Highpath as it is what provides the PSTN service. If this is the case I would say that you’re setup in the Highpath is incorrect as why would you send calls off to an outside system if the service is handled within the system where the call first originated from?
If I’m reading this all wrong, please get back with a clearer outline of what your intended call path is. Outline it in steps beginning with the calling device and onwards for each step of the call flow. The more details you give, the easier it is for an outsider to understand what you’re trying to accomplish.
Hi,
thank you for your continous feedback, I attached the topology below, I have no information/knowledge on the hipath system and it was configured by a 3rd party company, but what I know is off-net calls from the hipath are forwarded to the CM and the CM send to our Voice Gateway which is Cisco2921 and then we have an E1 link connected to e-gate (GSM gateway) which has about 24 simcard that connects to the operator.
Thank you, this makes it much clearer. So you are not using the Highpath system for international calls, you are using CM for this. This was not very clear in your previous reply’s. By this you need to have any partition(s) that grants access to external call routing available in the inbound CSS of the SIP trunk from the Highpath system. Apart from this you also need to grant access to the partition(s) where you have the directory numbers in the 1XXX and 2XXX ranges in CM.
What you do not want/need to grant access to is any route patterns that sends calls to the Highpath system, ie do not give the inbound CSS access to any partition(s) that holds the route patterns for 3XXX, 4XXX and 5XXX.
From what I can tell this would be the only reason for why you could have a call routing loop.
You have yet not shared a screenshot of the content of the inbound CSS, you have only shared parts of what it would grant access to with this piece of information “the pattern of the international CSS is (9.00!)”. This is btw not an accurate description as the CSS does not hold any patterns, that would be a Partition. As a hopefully last effort can you please share a screenshot of what partitions you have in the CSS that you use as inbound on the trunk and as well outline what exactly each partition gives access to?
Also please note that if there are no CSS that grants access to only the needed partitions you can simply create a new one and craft it as needed so that it only gives the trunk from the Highpath system access to what it needs and then set it as the trunk’s inbound CSS.
Hi,
sorry I did not get a notification about your previous reply, please check below route patterns...
Thank you, but that’s half or part of the information that I asked for. Can you please take a screenshot of the CSS used as the inbound CSS on the SIP trunk from the Highpath system? I want to see the list of partitions that is made available by the CSS. Without that the list of router patterns is just a list of patterns, that says nothing if they can be reached by the inbound CSS.
Apart from this, I thought that extensions 1XXX and 2XXX were directory numbers in CM. If so why are there route patterns that sends these to something named “VG”?
Also what is the route pattern 9.00 in the partition FMC_Internal used for?
