Introduction
This document describes the issue when calls that come in to Slave T1 IP Media Gateway (TIMG) or PBX IP Media Gateway (PIMG) are not routed correctly. TIMGs and PIMGs make it possible for PBXs to integrate to Unity Connection for voicemail access. Some PBXs require that this integration be via Simplified Message Desk Interface (SMDI), MCI, or MD-110. This means that calling information will be passed via a serial port connection from the PBX to the TIMG or PIMG. The TIMG or PIMG that the serial cable connects to will be configured as a Master. If there are other TIMGs or PIMGs required, these will be configured as Slaves and will look to the Master for calling information.
Problem
There are two or more TIMGs/PIMGs with a Master and Slave configuration. When a call comes into the Master, the call is forwarded to the proper Unity Connection voicemail box greeting.
Here is an example screenshot of the page from a Master PIMG:
However, when the call comes into the Slave TIMG the call is answered by the Opening Greeting. The call rolls to the Opening Greeting because the invite sent to Unity Connection from TIMG does not have a 'Diversion:' line within to say which mailbox extension the call should go to.
Here is an example of calling information seen on the Master:
08-28 17:54:28.078 [Si ] Prot 0D
08-28 17:54:28.078 [Si ] Prot 0A
08-28 17:54:28.078 [Si ] Prot 4D
08-28 17:54:28.078 [Si ] Prot 44
08-28 17:54:28.078 [Si ] Prot 30
08-28 17:54:28.078 [Si ] Prot 30
08-28 17:54:28.078 [Si ] Prot 30
08-28 17:54:28.078 [Si ] Prot 30
08-28 17:54:28.078 [Si ] Prot 30
08-28 17:54:28.078 [Si ] Prot 30
08-28 17:54:28.078 [Si ] Prot 31
08-28 17:54:28.078 [Si ] Prot 4E
08-28 17:54:28.078 [Si ] Prot 31
08-28 17:54:28.078 [Si ] Prot 39
08-28 17:54:28.078 [Si ] Prot 31
08-28 17:54:28.078 [Si ] Prot 38
08-28 17:54:28.078 [Si ] Prot 20
08-28 17:54:28.078 [Si ] Prot 39
08-28 17:54:28.078 [Si ] Prot 31
08-28 17:54:28.078 [Si ] Prot 39
08-28 17:54:28.078 [Si ] Prot 33
08-28 17:54:28.078 [Si ] Prot 33
08-28 17:54:28.078 [Si ] Prot 33
08-28 17:54:28.078 [Si ] Prot 33
08-28 17:54:28.078 [Si ] Prot 34
08-28 17:54:28.078 [Si ] Prot 38
08-28 17:54:28.078 [Si ] Prot 35
08-28 17:54:28.078 [Si ] Prot 20
08-28 17:54:28.078 [Si ] Prot 0D
08-28 17:54:28.078 [Si ] Prot 0A
08-28 17:54:28.078 [Si ] Code siSrvSerialInputEvent
08-28 17:54:28.078 [Si ] Prot From Serial: 0D 0A 4D 44 30 30 30 30 30 30 31
4E 31 39 31 38 20 39 31 39 33 33 33 33 34 38 35 20 0D 0A 19 00
08-28 17:54:28.078 [Si ] Prot 19
08-28 17:54:28.078 [Si ] Code siSrvPrcCpidFromSwitch ltn = 1,
src=9133333485, Dst = <NULL>, Redir = 1918, Reason = NoAns
08-28 17:54:28.078 [SiIp ] Code sertrans_ServerLocateClient 1
08-28 17:54:28.078 [SiIp ] Code sertrans_ServerLocateClient 1=client1
08-28 17:54:28.078 [SiIp ] Code _TaskMainClientReceive received data 516
08-28 17:54:28.078 [Si ] Code serial_client_cb
08-28 17:54:28.078 [Si ] Code SI_TYPE_CPID 1:NoAns (9193333485->->1918)
08-28 17:54:28.078 [Tel-1 ] Code GetChannelFromLogicalChannelNum
LogicalChanNum 0 span 0 channel 1
08-28 17:54:28.078 [Tel-1 ] Code t1casReportNewCpid
08-28 17:54:28.078 [Tel-1 ] Event Cpid (9193333485,->,->1918,) (NoAns)
08-28 17:54:28.078 [Tel-1 ] Warn t1casReportNewCpid err: no call for cpid
08-28 17:54:28.078 [Tel-1 ] Code t1casReportNewCpid saving pre-call cpid for
serial
08-28 17:54:29.195 [SiIp ] Code _TaskMainServerReceive(4) received 516 bytes
08-28 17:54:29.195 [SiIp ] Code _TaskMainServerReceive(4) keep-alive 1
received
08-28 17:54:29.195 [SiIp ] Code _TaskMainServerReceive(4) sending keep-alive
response
Here is an example of a problem invite seen on the Slave:
08-28 17:54:30.453 [VoIP ] Prot <----INVITE sip:Anonymous@14.48.4.88:5060 SIP/2.0
08-28 17:54:30.453 [VoIP ] Prot From:"Anonymous"<sip:Anonymous@14.48.4.92:5060;
user=phone>;vnd.pimg.port=1;tag=133B324631353641000BCF02
08-28 17:54:30.453 [VoIP ] Prot To:"Anonymous"<sip:Anonymous@14.48.4.88:5060>
08-28 17:54:30.453 [VoIP ] Prot Contact:<sip:14.48.4.92:5060>
08-28 17:54:30.453 [VoIP ] Prot Content-Type:application/sdp
08-28 17:54:30.453 [VoIP ] Prot Supported:replaces,early-session,100rel
08-28 17:54:30.453 [VoIP ] Prot Allow:INVITE,BYE,CANCEL,REFER,NOTIFY,OPTIONS,
REGISTER,INFO,ACK,PRACK
08-28 17:54:30.453 [VoIP ] Prot Expires:120
08-28 17:54:30.453 [VoIP ] Prot Call-ID:02061555D6F5009A000012BC@test.local
08-28 17:54:30.453 [VoIP ] Prot CSeq:1 INVITE
08-28 17:54:30.453 [VoIP ] Prot Max-Forwards:70
08-28 17:54:30.453 [VoIP ] Prot User-Agent:PBX-IP Media Gateway
08-28 17:54:30.453 [VoIP ] Prot Via:SIP/2.0/UDP 14.48.4.92:5060;
branch=z9hG4bKDC0A05314DD4ED48CEEEA72BD196FC38
08-28 17:54:30.453 [VoIP ] Prot Content-Length:245
This happens because the calling information is forwarded across the serial cable to the Master TIMG/PIMG, but the Logical Terminal Number (LTN) information does not match up to the port on the T1 Central Authentication Service (CAS) the physical call came in on.
Solution
On TIMG, select Configuration > Serial > Switch Protocol in order to configure the Logical Extension Numbers for each port.
Match the TIMG LTN and the port number from the PBX setting. The PBX has a table that shows you which channel on which T1 CAS line uses which LTN. Determine this information from the PBX first and set it accordingly in the TIMG. It is possible to use LTN 1-24 for Master channel 1-24 and LTN 25-48 for Slave channel 1-24.
Related Information