>From Show application stripMSD
StripMSD(count): Strips the leading 'count' digits from the
channel's
associated extension. For example, the number 5551212 when stripped with
a
count of 3 would be changed to 1212. This app always returns 0, and the
PBX
will continue processing at the next priority for the *new* extension.
So, for example, if priority 3 of 5551212 is StripMSD 3, the next step
executed will be priority 4 of 1212. If you switch into an extension
which
has no first step, the PBX will treat it as though the user dialed an
invalid extension.
It is expecting the next step to be:
_XXXXXXXXXX,2,Dial(Zap/g1/${EXTEN})
> -----Original Message-----
> From: asterisk-users-bounces@lists.digium.com
> [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of
> Jim Gottlieb
> Sent: Monday, September 26, 2005 11:28 PM
> To: asterisk-users@lists.digium.com
> Subject: [Asterisk-Users] StripMSD or extension parser bug?
>
> For years we've had the following simple context for outgoing calls:
>
> [outtrunk]
> ; match any NANP, and strip leading 1 off exten =>
> _1XXXXXXXXXX,1,StripMSD,1 ; dial outbound on trunk group 1
> exten => _XXXXXXXXXX,2,Dial,Zap/g1/${EXTEN}
>
>
> But when I upgraded on Friday to the latest CVSHEAD, this no
> longer works. If I send 13115552368 to this context, I get a
> message like
>
> pbx.c: Channel 'Zap/361-1' sent into invalid extension
> '3115552368' in context 'outtrunk', but no invalid handler
>
> I tried adding a separate line to match 10D:
>
> exten => _XXXXXXXXXX,1,Dial,Zap/g1/${EXTEN}
>
> but the same call generated a "timeout".
>
> I don't know if this is a bug in StripMSD, extension parsing,
> or user error.
> _______________________________________________
> --Bandwidth and Colocation sponsored by Easynews.com --
>
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
>