SMDR reporting of XNET/IP trunks

[vlevalois]

We have two MCD's (one 3300 and one vMCD) networked with IP trunks. The vMCD also has SIP trunks that the 3300 uses via the XNET IP trunks. I'd like to report on the SIP trunk activity of the XNET trunks in Prairiefyre, however I don't see any options on the XNET trunks to provide a reporting number or tag SMDR other than in COS options which is already set. Would the system report on calls even though it has no extension info, etc.? I've turned off SMDR reporting on the far side 3300 for the XNET trunks in hopes that would not mess things up but no dice.

Thanks.

 

[SXWizard]

In the SIP Peer Profile form there is a SMDR Tag field where you can enter a number that will appear for SIP trunks in SMDR records. Something like 9000 or 8888 would work and would report as X9000 or X8888. IP trunks always report X9999 in SMDR records as their trunk number. SMDR will report all SIP and IP trunk calls as long as you have the proper COS settings for trunks and stations.

(Note: the number of characters that report for the trunk can be 3 or 4 depending on a setting in the SMDR form. Standard reporting will be shown as T or X plus 3 digits, o.e.X999. If you enable Extended Reporting then you will see T or X plus 4 digits, i.e.X9999.) Be sure you use all the recommended PrairieFyre SMDR settings so that it can read the data correctly.

 

[vlevalois]

Thank you. We had already set the trunks as reporting number "5" and that's working fine for extension calls, however nothing for any other type of call i.e. XNET calls. Something we're missing?

 

[SXWizard]

XNET should be reporting as X9999. Check the COS for the XNET trunks and be sure SMDR External is enabled. For SMDR to report on calls the SMDR External option must be enabled for both the station making the call and the trunk the call is going out on.

 

[vlevalois]

OK so then do I need to add X9999 in Prairiefyre as a trunk group?

 

[SXWizard]

I would suggest going to Maintenance on the 3300 and entering "logs read smdr newest 100 match x9" and see if you get any match. That will at least show that the SMDR is being captured for XNET trunks.

 

[slapin]

The problem here that IP trunks are virtual and SMDR is reported based on endpoint activities only. There are no lines or actual "pipe" attached to the call. This is the reason that ICP is tagging all XNET/IP calls as x9999

SIP trunks are processed in a similar way as endpoints, so a tag can be attached to the SIP peer.

I don't think that there is any easy way to report traffic volume over XNET/IP trunks to individual remote controllers.

A more complex way would be mapping all the extensions and read DNIS field of an SMDR record and then group by ICP. This will not give detailed view to the actual call routing process, for example if you have IP trunks routed in "tandem" trough one or more controller until the call will reach the final destination, SMDR will report source and destination as IP trunk, but ANI and DNIS will be associated with the final destination.