Calls coming into our LRN
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution? ---Chris
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/ It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers.
Since those calls would be doomed to fail if your long-suffering receptionist wasn't in the loop, send 'em off to a custom treatment/intercept. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Paul Timmins Sent: Monday, November 08, 2010 2:32 PM To: Chris Wallace Cc: VoiceOps Subject: Re: [VoiceOps] Calls coming into our LRN On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/ It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Preferrably one like 'Hi, Your long distance carrier has made a grave error on their interconnection configuration. Please contact your long distance carrier for help'. Or even better "Hi, your long distance carrier made a serious mistake in routing this call. If you'd like more reliable long distance service feel free to give us a call at xxx-xxx-xxxx. Otherwise, call your long distance company and ask them to make sure they're passing Generic Address Parameter to our tandem." :) -Paul On 11/08/2010 05:49 PM, Hiers, David wrote:
Since those calls would be doomed to fail if your long-suffering receptionist wasn't in the loop, send 'em off to a custom treatment/intercept.
David Hiers
CCIE (R/S, V), CISSPaero bars ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Paul Timmins Sent: Monday, November 08, 2010 2:32 PM To: Chris Wallace Cc: VoiceOps Subject: Re: [VoiceOps] Calls coming into our LRN
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Today we got hammered with calls from MetroPCS. I will get a ticket open with our LD carrier. Thanks again! ---Chris On Mon, 08 Nov 2010 17:31:54 -0500, Paul Timmins <paul at timmins.net> wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers.
Open a ticket with MetroPCS - this problem is either happening at the MetroPCS handoff to the tandem, or via your tandem operator. lists at iamchriswallace.com wrote:
Today we got hammered with calls from MetroPCS. I will get a ticket open with our LD carrier. Thanks again!
---Chris
On Mon, 08 Nov 2010 17:31:54 -0500, Paul Timmins <paul at timmins.net> wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers.
BTW, thanks for the object lesson in overloading. Someone succumbed an attack of the clevers, and now you've got a mess on your hands.... David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of lists at iamchriswallace.com Sent: Monday, November 08, 2010 6:59 PM To: Paul Timmins Cc: VoiceOps Subject: Re: [VoiceOps] Calls coming into our LRN Today we got hammered with calls from MetroPCS. I will get a ticket open with our LD carrier. Thanks again! ---Chris On Mon, 08 Nov 2010 17:31:54 -0500, Paul Timmins <paul at timmins.net> wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
For these cases, do you typically see the number translated bit in the Forward Call Indicator set? On Nov 8, 2010, at 5:31 PM, Paul Timmins wrote: On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/ It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
That doesn't get logged in our CDRs so unless i was running debugs on the switch for our LRN at the time I wouldn't know. On 11/09/2010 07:42 AM, Michael Lunsford wrote:
For these cases, do you typically see the number translated bit in the Forward Call Indicator set?
On Nov 8, 2010, at 5:31 PM, Paul Timmins wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Does anyone have contact information for MetroPCS? We are still getting hammered with calls today and our tandem operator says there isn't much they can do (which I figured). Below are some examples traces, the first is a call to a ported number that is working correctly, the second is a call without the GAP information. 13:59:29.307 t3lrn1 MTP3 << ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:04114 DN: 2393330000 Us 13:59:29.307 t3lrn1 MTP3 er to user inds: <Absent> User to user info: <Absent> 13:59:29.307 t3lrn1 MTP3 12100100 20110A03 060D0380 90A20703 .... ........... 13:59:29.307 t3lrn1 MTP3 10323933 00000A07 03133229 325481EA .293......2)2T.. 13:59:29.307 t3lrn1 MTP3 013E3D01 14C008C0 03103269 980000C4 .>=.......2i.... 13:59:29.307 t3lrn1 MTP3 03532231 00 .S"1. 13:59:29.307 t3lrn1 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.307 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 13:59:29.307 t3lrn1 MTP3 00 Nature of connection indicators 13:59:29.307 t3lrn1 MTP3 2011 Forward call indicators 13:59:29.307 t3lrn1 MTP3 0A Calling party's category 13:59:29.307 t3lrn1 MTP3 8090A2 User service information 13:59:29.307 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 03133229325481 Calling party number: 2392234518 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 3E Originating line information 13:59:29.307 t3lrn1 MTP3 14 Hop counter 13:59:29.307 t3lrn1 MTP3 C003103269980000 Generic address/number: 2396890000 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 532231 Jurisdiction 13:59:29.488 t3lrn1 46576948:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:04114 Conn No: <Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 User to user inds: <Absent> User to user info: <Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 12100901 11020414 00 ......... 13:59:29.488 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.488 t3lrn1 46576948:0001 MTP3 09 Message type: ANM - Answer message. 13:59:29.488 t3lrn1 46576948:0001 MTP3 0414 Backward call indicators 13:59:34.607 t3lrn1 46576948:0001 MTP3 << ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:04114 CAUSE: Normal cle 13:59:34.607 t3lrn1 46576948:0001 MTP3 aring User to user inds: <Absent> User to user info: <Absent> 13:59:34.607 t3lrn1 46576948:0001 MTP3 12100C02 00028090 ........ 13:59:34.607 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:34.607 t3lrn1 46576948:0001 MTP3 0C Message type: REL - Release. 13:59:34.607 t3lrn1 46576948:0001 MTP3 8090 Cause indicators: Normal clearing 13:59:34.607 t3lrn1 46576948:0001 MTP3 Coding Standard: ITU-T 13:59:34.607 t3lrn1 46576948:0001 MTP3 Location: User 15:13:34.145 t3lrn1 MTP3 << ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:01286 DN: 2393330000 Us 15:13:34.145 t3lrn1 MTP3 er to user inds: <Absent> User to user info: <Absent> 15:13:34.145 t3lrn1 MTP3 06050110 28100003 060D0380 90A20703 ....(........... 15:13:34.145 t3lrn1 MTP3 10323933 0000EA01 0000 .293...... 15:13:34.145 t3lrn1 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.145 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 15:13:34.145 t3lrn1 MTP3 10 Nature of connection indicators 15:13:34.145 t3lrn1 MTP3 2810 Forward call indicators 15:13:34.145 t3lrn1 MTP3 00 Calling party's category 15:13:34.145 t3lrn1 MTP3 8090A2 User service information 15:13:34.145 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 15:13:34.145 t3lrn1 MTP3 National number 15:13:34.145 t3lrn1 MTP3 00 Originating line information 15:13:34.305 t3lrn1 46596545:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:01286 Conn No: <Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 User to user inds: <Absent> User to user info: <Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 06050901 11020414 00 ......... 15:13:34.305 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.305 t3lrn1 46596545:0001 MTP3 09 Message type: ANM - Answer message. 15:13:34.305 t3lrn1 46596545:0001 MTP3 0414 Backward call indicators 15:13:58.744 t3lrn1 46596545:0001 MTP3 << ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:01286 CAUSE: Normal cle 15:13:58.744 t3lrn1 46596545:0001 MTP3 aring User to user inds: <Absent> User to user info: <Absent> 15:13:58.744 t3lrn1 46596545:0001 MTP3 06050C02 00028490 ........ 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 0C Message type: REL - Release. 15:13:58.744 t3lrn1 46596545:0001 MTP3 8490 Cause indicators: Normal clearing 15:13:58.744 t3lrn1 46596545:0001 MTP3 Coding Standard: ITU-T 15:13:58.744 t3lrn1 46596545:0001 MTP3 Location: Remote public network 15:13:58.744 t3lrn1 46596545:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: RLC DPC:[239.009.026] CIC:01286 15:13:58.744 t3lrn1 46596545:0001 MTP3 060510 ... 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 10 Message type: RLC - Release complete. ---Chris On Nov 9, 2010, at 10:00 AM, Paul Timmins wrote:
That doesn't get logged in our CDRs so unless i was running debugs on the switch for our LRN at the time I wouldn't know.
On 11/09/2010 07:42 AM, Michael Lunsford wrote:
For these cases, do you typically see the number translated bit in the Forward Call Indicator set?
On Nov 8, 2010, at 5:31 PM, Paul Timmins wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Notice the indication of "Interworking encountered" in the Forward Call Indicator of the 2nd call. Very possible that the interworking point is the source of the failure. - michael On Nov 9, 2010, at 11:45 AM, Chris Wallace wrote: Does anyone have contact information for MetroPCS? We are still getting hammered with calls today and our tandem operator says there isn't much they can do (which I figured). Below are some examples traces, the first is a call to a ported number that is working correctly, the second is a call without the GAP information. 13:59:29.307 t3lrn1 MTP3 << ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:04114 DN: 2393330000 Us 13:59:29.307 t3lrn1 MTP3 er to user inds: <Absent> User to user info: <Absent> 13:59:29.307 t3lrn1 MTP3 12100100 20110A03 060D0380 90A20703 .... ........... 13:59:29.307 t3lrn1 MTP3 10323933 00000A07 03133229 325481EA .293......2)2T.. 13:59:29.307 t3lrn1 MTP3 013E3D01 14C008C0 03103269 980000C4 .>=.......2i.... 13:59:29.307 t3lrn1 MTP3 03532231 00 .S"1. 13:59:29.307 t3lrn1 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.307 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 13:59:29.307 t3lrn1 MTP3 00 Nature of connection indicators 13:59:29.307 t3lrn1 MTP3 2011 Forward call indicators 13:59:29.307 t3lrn1 MTP3 0A Calling party's category 13:59:29.307 t3lrn1 MTP3 8090A2 User service information 13:59:29.307 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 03133229325481 Calling party number: 2392234518 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 3E Originating line information 13:59:29.307 t3lrn1 MTP3 14 Hop counter 13:59:29.307 t3lrn1 MTP3 C003103269980000 Generic address/number: 2396890000 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 532231 Jurisdiction 13:59:29.488 t3lrn1 46576948:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:04114 Conn No: <Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 User to user inds: <Absent> User to user info: <Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 12100901 11020414 00 ......... 13:59:29.488 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.488 t3lrn1 46576948:0001 MTP3 09 Message type: ANM - Answer message. 13:59:29.488 t3lrn1 46576948:0001 MTP3 0414 Backward call indicators 13:59:34.607 t3lrn1 46576948:0001 MTP3 << ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:04114 CAUSE: Normal cle 13:59:34.607 t3lrn1 46576948:0001 MTP3 aring User to user inds: <Absent> User to user info: <Absent> 13:59:34.607 t3lrn1 46576948:0001 MTP3 12100C02 00028090 ........ 13:59:34.607 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:34.607 t3lrn1 46576948:0001 MTP3 0C Message type: REL - Release. 13:59:34.607 t3lrn1 46576948:0001 MTP3 8090 Cause indicators: Normal clearing 13:59:34.607 t3lrn1 46576948:0001 MTP3 Coding Standard: ITU-T 13:59:34.607 t3lrn1 46576948:0001 MTP3 Location: User 15:13:34.145 t3lrn1 MTP3 << ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:01286 DN: 2393330000 Us 15:13:34.145 t3lrn1 MTP3 er to user inds: <Absent> User to user info: <Absent> 15:13:34.145 t3lrn1 MTP3 06050110 28100003 060D0380 90A20703 ....(........... 15:13:34.145 t3lrn1 MTP3 10323933 0000EA01 0000 .293...... 15:13:34.145 t3lrn1 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.145 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 15:13:34.145 t3lrn1 MTP3 10 Nature of connection indicators 15:13:34.145 t3lrn1 MTP3 2810 Forward call indicators 15:13:34.145 t3lrn1 MTP3 00 Calling party's category 15:13:34.145 t3lrn1 MTP3 8090A2 User service information 15:13:34.145 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 15:13:34.145 t3lrn1 MTP3 National number 15:13:34.145 t3lrn1 MTP3 00 Originating line information 15:13:34.305 t3lrn1 46596545:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:01286 Conn No: <Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 User to user inds: <Absent> User to user info: <Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 06050901 11020414 00 ......... 15:13:34.305 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.305 t3lrn1 46596545:0001 MTP3 09 Message type: ANM - Answer message. 15:13:34.305 t3lrn1 46596545:0001 MTP3 0414 Backward call indicators 15:13:58.744 t3lrn1 46596545:0001 MTP3 << ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:01286 CAUSE: Normal cle 15:13:58.744 t3lrn1 46596545:0001 MTP3 aring User to user inds: <Absent> User to user info: <Absent> 15:13:58.744 t3lrn1 46596545:0001 MTP3 06050C02 00028490 ........ 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 0C Message type: REL - Release. 15:13:58.744 t3lrn1 46596545:0001 MTP3 8490 Cause indicators: Normal clearing 15:13:58.744 t3lrn1 46596545:0001 MTP3 Coding Standard: ITU-T 15:13:58.744 t3lrn1 46596545:0001 MTP3 Location: Remote public network 15:13:58.744 t3lrn1 46596545:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: RLC DPC:[239.009.026] CIC:01286 15:13:58.744 t3lrn1 46596545:0001 MTP3 060510 ... 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 10 Message type: RLC - Release complete. ---Chris On Nov 9, 2010, at 10:00 AM, Paul Timmins wrote:
That doesn't get logged in our CDRs so unless i was running debugs on the switch for our LRN at the time I wouldn't know.
On 11/09/2010 07:42 AM, Michael Lunsford wrote:
For these cases, do you typically see the number translated bit in the Forward Call Indicator set?
On Nov 8, 2010, at 5:31 PM, Paul Timmins wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
So would that be MetroPCS or would that be our Tandem (CenturyLink)? ---Chris On Nov 9, 2010, at 12:11 PM, Michael Lunsford wrote:
Notice the indication of "Interworking encountered" in the Forward Call Indicator of the 2nd call. Very possible that the interworking point is the source of the failure.
- michael
On Nov 9, 2010, at 11:45 AM, Chris Wallace wrote:
Does anyone have contact information for MetroPCS? We are still getting hammered with calls today and our tandem operator says there isn't much they can do (which I figured).
Below are some examples traces, the first is a call to a ported number that is working correctly, the second is a call without the GAP information.
13:59:29.307 t3lrn1 MTP3 << ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:04114 DN: 2393330000 Us 13:59:29.307 t3lrn1 MTP3 er to user inds: <Absent> User to user info: <Absent> 13:59:29.307 t3lrn1 MTP3 12100100 20110A03 060D0380 90A20703 .... ........... 13:59:29.307 t3lrn1 MTP3 10323933 00000A07 03133229 325481EA .293......2)2T.. 13:59:29.307 t3lrn1 MTP3 013E3D01 14C008C0 03103269 980000C4 .>=.......2i.... 13:59:29.307 t3lrn1 MTP3 03532231 00 .S"1. 13:59:29.307 t3lrn1 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.307 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 13:59:29.307 t3lrn1 MTP3 00 Nature of connection indicators 13:59:29.307 t3lrn1 MTP3 2011 Forward call indicators 13:59:29.307 t3lrn1 MTP3 0A Calling party's category 13:59:29.307 t3lrn1 MTP3 8090A2 User service information 13:59:29.307 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 03133229325481 Calling party number: 2392234518 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 3E Originating line information 13:59:29.307 t3lrn1 MTP3 14 Hop counter 13:59:29.307 t3lrn1 MTP3 C003103269980000 Generic address/number: 2396890000 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 532231 Jurisdiction 13:59:29.488 t3lrn1 46576948:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:04114 Conn No: <Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 User to user inds: <Absent> User to user info: <Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 12100901 11020414 00 ......... 13:59:29.488 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.488 t3lrn1 46576948:0001 MTP3 09 Message type: ANM - Answer message. 13:59:29.488 t3lrn1 46576948:0001 MTP3 0414 Backward call indicators 13:59:34.607 t3lrn1 46576948:0001 MTP3 << ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:04114 CAUSE: Normal cle 13:59:34.607 t3lrn1 46576948:0001 MTP3 aring User to user inds: <Absent> User to user info: <Absent> 13:59:34.607 t3lrn1 46576948:0001 MTP3 12100C02 00028090 ........ 13:59:34.607 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:34.607 t3lrn1 46576948:0001 MTP3 0C Message type: REL - Release. 13:59:34.607 t3lrn1 46576948:0001 MTP3 8090 Cause indicators: Normal clearing 13:59:34.607 t3lrn1 46576948:0001 MTP3 Coding Standard: ITU-T 13:59:34.607 t3lrn1 46576948:0001 MTP3 Location: User
15:13:34.145 t3lrn1 MTP3 << ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:01286 DN: 2393330000 Us 15:13:34.145 t3lrn1 MTP3 er to user inds: <Absent> User to user info: <Absent> 15:13:34.145 t3lrn1 MTP3 06050110 28100003 060D0380 90A20703 ....(........... 15:13:34.145 t3lrn1 MTP3 10323933 0000EA01 0000 .293...... 15:13:34.145 t3lrn1 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.145 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 15:13:34.145 t3lrn1 MTP3 10 Nature of connection indicators 15:13:34.145 t3lrn1 MTP3 2810 Forward call indicators 15:13:34.145 t3lrn1 MTP3 00 Calling party's category 15:13:34.145 t3lrn1 MTP3 8090A2 User service information 15:13:34.145 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 15:13:34.145 t3lrn1 MTP3 National number 15:13:34.145 t3lrn1 MTP3 00 Originating line information 15:13:34.305 t3lrn1 46596545:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:01286 Conn No: <Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 User to user inds: <Absent> User to user info: <Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 06050901 11020414 00 ......... 15:13:34.305 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.305 t3lrn1 46596545:0001 MTP3 09 Message type: ANM - Answer message. 15:13:34.305 t3lrn1 46596545:0001 MTP3 0414 Backward call indicators 15:13:58.744 t3lrn1 46596545:0001 MTP3 << ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:01286 CAUSE: Normal cle 15:13:58.744 t3lrn1 46596545:0001 MTP3 aring User to user inds: <Absent> User to user info: <Absent> 15:13:58.744 t3lrn1 46596545:0001 MTP3 06050C02 00028490 ........ 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 0C Message type: REL - Release. 15:13:58.744 t3lrn1 46596545:0001 MTP3 8490 Cause indicators: Normal clearing 15:13:58.744 t3lrn1 46596545:0001 MTP3 Coding Standard: ITU-T 15:13:58.744 t3lrn1 46596545:0001 MTP3 Location: Remote public network 15:13:58.744 t3lrn1 46596545:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: RLC DPC:[239.009.026] CIC:01286 15:13:58.744 t3lrn1 46596545:0001 MTP3 060510 ... 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 10 Message type: RLC - Release complete.
---Chris
On Nov 9, 2010, at 10:00 AM, Paul Timmins wrote:
That doesn't get logged in our CDRs so unless i was running debugs on the switch for our LRN at the time I wouldn't know.
On 11/09/2010 07:42 AM, Michael Lunsford wrote:
For these cases, do you typically see the number translated bit in the Forward Call Indicator set?
On Nov 8, 2010, at 5:31 PM, Paul Timmins wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
There is no way to tell from the IAM where it happened, only that it happened. Without knowledge of the path the call traversed, there is no way to know. You'll have to start at one end or the other and get assistance tracing the call. On Nov 9, 2010, at 12:14 PM, Chris Wallace wrote: So would that be MetroPCS or would that be our Tandem (CenturyLink)? ---Chris On Nov 9, 2010, at 12:11 PM, Michael Lunsford wrote:
Notice the indication of "Interworking encountered" in the Forward Call Indicator of the 2nd call. Very possible that the interworking point is the source of the failure.
- michael
On Nov 9, 2010, at 11:45 AM, Chris Wallace wrote:
Does anyone have contact information for MetroPCS? We are still getting hammered with calls today and our tandem operator says there isn't much they can do (which I figured).
Below are some examples traces, the first is a call to a ported number that is working correctly, the second is a call without the GAP information.
13:59:29.307 t3lrn1 MTP3 << ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:04114 DN: 2393330000 Us 13:59:29.307 t3lrn1 MTP3 er to user inds: <Absent> User to user info: <Absent> 13:59:29.307 t3lrn1 MTP3 12100100 20110A03 060D0380 90A20703 .... ........... 13:59:29.307 t3lrn1 MTP3 10323933 00000A07 03133229 325481EA .293......2)2T.. 13:59:29.307 t3lrn1 MTP3 013E3D01 14C008C0 03103269 980000C4 .>=.......2i.... 13:59:29.307 t3lrn1 MTP3 03532231 00 .S"1. 13:59:29.307 t3lrn1 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.307 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 13:59:29.307 t3lrn1 MTP3 00 Nature of connection indicators 13:59:29.307 t3lrn1 MTP3 2011 Forward call indicators 13:59:29.307 t3lrn1 MTP3 0A Calling party's category 13:59:29.307 t3lrn1 MTP3 8090A2 User service information 13:59:29.307 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 03133229325481 Calling party number: 2392234518 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 3E Originating line information 13:59:29.307 t3lrn1 MTP3 14 Hop counter 13:59:29.307 t3lrn1 MTP3 C003103269980000 Generic address/number: 2396890000 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 532231 Jurisdiction 13:59:29.488 t3lrn1 46576948:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:04114 Conn No: <Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 User to user inds: <Absent> User to user info: <Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 12100901 11020414 00 ......... 13:59:29.488 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.488 t3lrn1 46576948:0001 MTP3 09 Message type: ANM - Answer message. 13:59:29.488 t3lrn1 46576948:0001 MTP3 0414 Backward call indicators 13:59:34.607 t3lrn1 46576948:0001 MTP3 << ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:04114 CAUSE: Normal cle 13:59:34.607 t3lrn1 46576948:0001 MTP3 aring User to user inds: <Absent> User to user info: <Absent> 13:59:34.607 t3lrn1 46576948:0001 MTP3 12100C02 00028090 ........ 13:59:34.607 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:34.607 t3lrn1 46576948:0001 MTP3 0C Message type: REL - Release. 13:59:34.607 t3lrn1 46576948:0001 MTP3 8090 Cause indicators: Normal clearing 13:59:34.607 t3lrn1 46576948:0001 MTP3 Coding Standard: ITU-T 13:59:34.607 t3lrn1 46576948:0001 MTP3 Location: User
15:13:34.145 t3lrn1 MTP3 << ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:01286 DN: 2393330000 Us 15:13:34.145 t3lrn1 MTP3 er to user inds: <Absent> User to user info: <Absent> 15:13:34.145 t3lrn1 MTP3 06050110 28100003 060D0380 90A20703 ....(........... 15:13:34.145 t3lrn1 MTP3 10323933 0000EA01 0000 .293...... 15:13:34.145 t3lrn1 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.145 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 15:13:34.145 t3lrn1 MTP3 10 Nature of connection indicators 15:13:34.145 t3lrn1 MTP3 2810 Forward call indicators 15:13:34.145 t3lrn1 MTP3 00 Calling party's category 15:13:34.145 t3lrn1 MTP3 8090A2 User service information 15:13:34.145 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 15:13:34.145 t3lrn1 MTP3 National number 15:13:34.145 t3lrn1 MTP3 00 Originating line information 15:13:34.305 t3lrn1 46596545:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:01286 Conn No: <Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 User to user inds: <Absent> User to user info: <Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 06050901 11020414 00 ......... 15:13:34.305 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.305 t3lrn1 46596545:0001 MTP3 09 Message type: ANM - Answer message. 15:13:34.305 t3lrn1 46596545:0001 MTP3 0414 Backward call indicators 15:13:58.744 t3lrn1 46596545:0001 MTP3 << ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:01286 CAUSE: Normal cle 15:13:58.744 t3lrn1 46596545:0001 MTP3 aring User to user inds: <Absent> User to user info: <Absent> 15:13:58.744 t3lrn1 46596545:0001 MTP3 06050C02 00028490 ........ 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 0C Message type: REL - Release. 15:13:58.744 t3lrn1 46596545:0001 MTP3 8490 Cause indicators: Normal clearing 15:13:58.744 t3lrn1 46596545:0001 MTP3 Coding Standard: ITU-T 15:13:58.744 t3lrn1 46596545:0001 MTP3 Location: Remote public network 15:13:58.744 t3lrn1 46596545:0001 MTP3 >> ISUP variant: ANSI 1999 ISUP: RLC DPC:[239.009.026] CIC:01286 15:13:58.744 t3lrn1 46596545:0001 MTP3 060510 ... 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 10 Message type: RLC - Release complete.
---Chris
On Nov 9, 2010, at 10:00 AM, Paul Timmins wrote:
That doesn't get logged in our CDRs so unless i was running debugs on the switch for our LRN at the time I wouldn't know.
On 11/09/2010 07:42 AM, Michael Lunsford wrote:
For these cases, do you typically see the number translated bit in the Forward Call Indicator set?
On Nov 8, 2010, at 5:31 PM, Paul Timmins wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
If 2396890000 Is your number, this ISUP is correct. On 11/09/2010 11:45 AM, Chris Wallace wrote:
Does anyone have contact information for MetroPCS? We are still getting hammered with calls today and our tandem operator says there isn't much they can do (which I figured).
Below are some examples traces, the first is a call to a ported number that is working correctly, the second is a call without the GAP information.
13:59:29.307 t3lrn1 MTP3<< ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:04114 DN: 2393330000 Us 13:59:29.307 t3lrn1 MTP3 er to user inds:<Absent> User to user info:<Absent> 13:59:29.307 t3lrn1 MTP3 12100100 20110A03 060D0380 90A20703 .... ........... 13:59:29.307 t3lrn1 MTP3 10323933 00000A07 03133229 325481EA .293......2)2T.. 13:59:29.307 t3lrn1 MTP3 013E3D01 14C008C0 03103269 980000C4 .>=.......2i.... 13:59:29.307 t3lrn1 MTP3 03532231 00 .S"1. 13:59:29.307 t3lrn1 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.307 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 13:59:29.307 t3lrn1 MTP3 00 Nature of connection indicators 13:59:29.307 t3lrn1 MTP3 2011 Forward call indicators 13:59:29.307 t3lrn1 MTP3 0A Calling party's category 13:59:29.307 t3lrn1 MTP3 8090A2 User service information 13:59:29.307 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 03133229325481 Calling party number: 2392234518 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 3E Originating line information 13:59:29.307 t3lrn1 MTP3 14 Hop counter 13:59:29.307 t3lrn1 MTP3 C003103269980000 Generic address/number: 2396890000 13:59:29.307 t3lrn1 MTP3 Presentation Allowed 13:59:29.307 t3lrn1 MTP3 National number 13:59:29.307 t3lrn1 MTP3 532231 Jurisdiction 13:59:29.488 t3lrn1 46576948:0001 MTP3>> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:04114 Conn No:<Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 User to user inds:<Absent> User to user info:<Absent> 13:59:29.488 t3lrn1 46576948:0001 MTP3 12100901 11020414 00 ......... 13:59:29.488 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:29.488 t3lrn1 46576948:0001 MTP3 09 Message type: ANM - Answer message. 13:59:29.488 t3lrn1 46576948:0001 MTP3 0414 Backward call indicators 13:59:34.607 t3lrn1 46576948:0001 MTP3<< ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:04114 CAUSE: Normal cle 13:59:34.607 t3lrn1 46576948:0001 MTP3 aring User to user inds:<Absent> User to user info:<Absent> 13:59:34.607 t3lrn1 46576948:0001 MTP3 12100C02 00028090 ........ 13:59:34.607 t3lrn1 46576948:0001 MTP3 ISUP variant: ANSI 1999 1210 CIC: 4114 13:59:34.607 t3lrn1 46576948:0001 MTP3 0C Message type: REL - Release. 13:59:34.607 t3lrn1 46576948:0001 MTP3 8090 Cause indicators: Normal clearing 13:59:34.607 t3lrn1 46576948:0001 MTP3 Coding Standard: ITU-T 13:59:34.607 t3lrn1 46576948:0001 MTP3 Location: User
15:13:34.145 t3lrn1 MTP3<< ISUP variant: ANSI 1999 ISUP: IAM OPC:[239.009.026] CIC:01286 DN: 2393330000 Us 15:13:34.145 t3lrn1 MTP3 er to user inds:<Absent> User to user info:<Absent> 15:13:34.145 t3lrn1 MTP3 06050110 28100003 060D0380 90A20703 ....(........... 15:13:34.145 t3lrn1 MTP3 10323933 0000EA01 0000 .293...... 15:13:34.145 t3lrn1 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.145 t3lrn1 MTP3 01 Message type: IAM - Initial address message. 15:13:34.145 t3lrn1 MTP3 10 Nature of connection indicators 15:13:34.145 t3lrn1 MTP3 2810 Forward call indicators 15:13:34.145 t3lrn1 MTP3 00 Calling party's category 15:13:34.145 t3lrn1 MTP3 8090A2 User service information 15:13:34.145 t3lrn1 MTP3 03103239330000 Called party number: 2393330000 15:13:34.145 t3lrn1 MTP3 National number 15:13:34.145 t3lrn1 MTP3 00 Originating line information 15:13:34.305 t3lrn1 46596545:0001 MTP3>> ISUP variant: ANSI 1999 ISUP: ANM DPC:[239.009.026] CIC:01286 Conn No:<Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 User to user inds:<Absent> User to user info:<Absent> 15:13:34.305 t3lrn1 46596545:0001 MTP3 06050901 11020414 00 ......... 15:13:34.305 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:34.305 t3lrn1 46596545:0001 MTP3 09 Message type: ANM - Answer message. 15:13:34.305 t3lrn1 46596545:0001 MTP3 0414 Backward call indicators 15:13:58.744 t3lrn1 46596545:0001 MTP3<< ISUP variant: ANSI 1999 ISUP: REL OPC:[239.009.026] CIC:01286 CAUSE: Normal cle 15:13:58.744 t3lrn1 46596545:0001 MTP3 aring User to user inds:<Absent> User to user info:<Absent> 15:13:58.744 t3lrn1 46596545:0001 MTP3 06050C02 00028490 ........ 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 0C Message type: REL - Release. 15:13:58.744 t3lrn1 46596545:0001 MTP3 8490 Cause indicators: Normal clearing 15:13:58.744 t3lrn1 46596545:0001 MTP3 Coding Standard: ITU-T 15:13:58.744 t3lrn1 46596545:0001 MTP3 Location: Remote public network 15:13:58.744 t3lrn1 46596545:0001 MTP3>> ISUP variant: ANSI 1999 ISUP: RLC DPC:[239.009.026] CIC:01286 15:13:58.744 t3lrn1 46596545:0001 MTP3 060510 ... 15:13:58.744 t3lrn1 46596545:0001 MTP3 ISUP variant: ANSI 1999 0605 CIC: 1286 15:13:58.744 t3lrn1 46596545:0001 MTP3 10 Message type: RLC - Release complete.
---Chris
On Nov 9, 2010, at 10:00 AM, Paul Timmins wrote:
That doesn't get logged in our CDRs so unless i was running debugs on the switch for our LRN at the time I wouldn't know.
On 11/09/2010 07:42 AM, Michael Lunsford wrote:
For these cases, do you typically see the number translated bit in the Forward Call Indicator set?
On Nov 8, 2010, at 5:31 PM, Paul Timmins wrote:
On 11/08/2010 04:37 PM, Chris Wallace wrote:
Years ago our switch tech decided to make our main company number the same as our LRN. We have had an ongoing issue where calls to an LNP'd number do not come into our switch with the original called number and they are routed into our company PBX and we end up becoming the switchboard for people trying to reach our customers. It seems as though we have been more and more of these calls lately. Has anyone dealt with a similar issue? If so, what was your resolution?
We have ours set up as RCFs to the network operations center so we know when there are LD providers stripping the generic address parameter, which would cause that. I've seen qwest do it a lot. :/
It's not happening often enough to be a problem, but it seems to happen more on our LATA 344 customers. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (4)
-
David_Hiers＠adp.com -
lists＠iamchriswallace.com -
Michael.Lunsford＠cbeyond.net -
paul＠timmins.net