Mitelpassion
IS-IT--Management
It took me a while to figure this one out. NOt sure if it's design intent or not but here goes, Hope this helps. I'd like to add in the beginning that the issue was not with the CLI as such rather the way the FROM address was formed in behaviour of CLI on or off.
Had an issue with SIP calls coming into a 3300 from a service provider.
This worked only when CLI from the calling party into the 3300 was turned on. When no CLI was turned on (FROM anonymous) then the call was rejected by the controller with 404 NOT FOUND eventhough the number being dialled did exist on the the controller.
Here was the problem. The SP for some reason displayed anonymousATcompanyDOTcom when CLI was disabled (anonymous I understand). When CLI was turned on, on the calling device then the SP showed '1234567890'@IPaddress.
In short the 3300 rejected the call when the domain name was shown. This was due to the fact that the info in the Network Element setup didn't contain the domain name.
The Mitel rejected the calls that had a FROM domain or IP that was not listed.
I fixed this by adding another network element in addition to the one already created for SIP to the SP. Same SP remember, same account!
However in the portion of the IP or FQDN field directly under the option of 3300, outbound PROXY or other, I added the domain name excately (or you add the IP if the SIP FROM address displays @IP address) as it appeared in the SIP messages.
I then ticked the little tick box to define the SIP info. However the stuff I put in here was fictitious.
Then I went to SIP peer profile and added another fictitious entry with garbage info and registration detail BUT I selected my newly created 'domain name' element in the drop-down list.
Somehow the controller then added this to it's "Trusted/allowed" domains and the call with no CLI that displayed a domain name instead of IP address in the FROM field worked even though the newly created entries contained bogus detail.
Had an issue with SIP calls coming into a 3300 from a service provider.
This worked only when CLI from the calling party into the 3300 was turned on. When no CLI was turned on (FROM anonymous) then the call was rejected by the controller with 404 NOT FOUND eventhough the number being dialled did exist on the the controller.
Here was the problem. The SP for some reason displayed anonymousATcompanyDOTcom when CLI was disabled (anonymous I understand). When CLI was turned on, on the calling device then the SP showed '1234567890'@IPaddress.
In short the 3300 rejected the call when the domain name was shown. This was due to the fact that the info in the Network Element setup didn't contain the domain name.
The Mitel rejected the calls that had a FROM domain or IP that was not listed.
I fixed this by adding another network element in addition to the one already created for SIP to the SP. Same SP remember, same account!
However in the portion of the IP or FQDN field directly under the option of 3300, outbound PROXY or other, I added the domain name excately (or you add the IP if the SIP FROM address displays @IP address) as it appeared in the SIP messages.
I then ticked the little tick box to define the SIP info. However the stuff I put in here was fictitious.
Then I went to SIP peer profile and added another fictitious entry with garbage info and registration detail BUT I selected my newly created 'domain name' element in the drop-down list.
Somehow the controller then added this to it's "Trusted/allowed" domains and the call with no CLI that displayed a domain name instead of IP address in the FROM field worked even though the newly created entries contained bogus detail.