I am just adding an English language version because I recently ran into the same issue and there is no blog in English about it.
If I ever wondered why we buy support from gateway vendors, this issue validated it for me.
We were bringing up a new location with a PRI. Through testing, I was able to make outbound calls but the people in the actual location were unable to complete the calls. This didn’t make sense. How can I make a successful call, sitting thousands of (pick one: miles/kilometers) away, and the people in the actual office could not?
In this case, our gateway was an AudioCodes Mediant 1000 and we were working with an AudioCodes engineer on the implementation. The AudioCodes engineer had given us numerous things to try to no avail. Finally he had us e-mail him some WireShark logs so he could spend more time on the issue.
A day later, he recommended that we set this value in our ini file:
ISO8859CharacterSet = 0
After making this change, the users in the location were suddenly able to make calls.
The issue is that the users in that location all use the following character in their display name as part of the spelling of their office location:
So what does this ISO8859CharacterSet value actually mean? For one, it’s not documented anywhere. I followed up with AudioCodes and they sent me the following documentation.
Basically, this value expands the default character set that AudioCodes uses to parse SIP traffic. Why isn’t it set to zero by default? Who knows. I asked that question to the AudioCodes engineer and he had no answer. I asked if maybe there was a performance impact to this value. He replied that there isn’t one that he knew of. I asked a second AudioCodes engineer and he confirmed that he had never heard of an issue by setting this to 0.
It’s surprising to us that we hadn’t run into this issue before but then our standards are to use the generic ASCII character set in all display names, usernames, etc.
How do you know you might have this issue? I don’t have the AudioCodes syslog files anymore so I swiped the below from the German blog mentioned above.
<132>[S=831454] Error Indication: Last Command (Primitive) was not performed due to cause 100 [Trunk:0 Bchannel:1 ConnID:2] [Code:0x23127]
<133>[S=831455] ( lgr_psbrdex)(833974 ) recv <– UnHandled event:EV_ISDN_ERROR_INDICATION (317)
<133>[S=831456] [SID:766997237] ( lgr_psbrdex)(833975 ) pstn recv <– CALL_RELEASED Trunk:0 Conn:2 RetCause:73 NetCause:255
<132>[S=831457] REPORT_TYPE_ERROR_IN: ErrorCauseString = Incorrect parameter type, DiagnosticString= Condition unknown, ErrorCause = d, Diagnostic = [Trunk:0 Bchannel:-1 ConnID:-1] [Code:0x23127]
<133>[S=831458] [SID:766997237] ( lgr_psbrdif)(833976 ) pstn send –> PlaceCall: Trunk:0 BChannel:1 ConnID:2 SrcPN=xxx SrcSN= DstPN=151xxxxxxxx DstSN= SrcNT=4 SrcNP=1 SrcPres=0 SrcScrn=0 DstNT=2 DstNP=1 ServiceCap=M RdrctNum= RdNT=0 RdNP=0 RdPres=0 RdScrn=0 RdRsn=-1 Excl=1 Display=Müller, Max IE= UUIE=0, RawData:0 CLIRReason:-1 OrigPN= OLI=-1 OffhookInd=0
<133>[S=831462] [SID:766997237] ( lgr_psbrdif)(833980 ) Abnormal Disconnect cause:255#?reason(255)? Trunk:0 Conn:2
If you see the above that’s a clue. In this case, it was the u-umlaut (ü) in “Müller, Max” causing the issue.