chan_ss7 decoding isup phone num

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Greg,

> One should probably also patch the "decode_isup_phonenum" function in isup.c
> as well so that it doesn't log a warning message and doesn't prepend '00' in
> respect of subscriber numbers. I didn't bother as the warning doesn't bother
> me and I'm just stripping the 00 off within the dialplan.

It's not a problem for us.. we also strip the 00 via dialplan. I just
was wondering why always was considered itnernational. Anyway, i will
give a test to your patch. Thanks.

> 
> Out of interest, in what circumstances do you receive NAI of subscriber
> number?

We have the pstn-gw connected to a local ewsd, doing a kind of expansion
(growing in sip now to remote users). Then the numbering plan is local
to the ewsd.

> 
> We receive it on calls to all numbers that have been ported into our network
> and have a port-code prepended to the number by the number block operator.
> 
> We send it on all calls to numbers that are short-coded operator numbers, e.g.
> three and four-digit numbers for services like directory enquiries. We also
> send it on all calls to numbers ported out of our network for which we've
> pre-pended the recipient operator's port code. Our port codes start with 'D'
> hence the patch to match the missing hex character digits.

Not our case, at least by now.

Regards,
Claudio

> 
> ----- Original Message ----- From: "Kristian Nielsen"
> <knielsen at knielsen-hq.org>
> To: <elcaio at gmail.com>
> Cc: <asterisk-ss7 at lists.digium.com>
> Sent: Wednesday, June 23, 2010 12:04 PM
> Subject: Re: [asterisk-ss7] chan_ss7 decoding isup phone num
> 
> 
> > Claudio Furrer <elcaio at gmail.com> writes:
> > 
> > > Does anybody know why chan_ss7 fall-through to international phone number,
> > > no
> > > matters if the number is national or subscriber local one? (I mean in
> > > incoming
> > > calls, from pstn).
> > 
> > It's my fault :) Here is the story ...
> > 
> > Back in 2005 when I wrote the original chan_ss7, our systems were running
> > inside the central switching point for a Danish mobile operator. In this
> > context, subscriber local makes little sense (we were running centrally, not
> > on a local end-subscriber switch, and Denmark have no subscriber-local
> > numbers
> > anyway, much less for mobile numbers).
> > 
> > At some point (I think even pre-chan_ss7), we had seen some rare occasions
> > where an incoming call would arrive from some exotic country with a calling
> > number that was obviously international (had a national prefix etc.), yet
> > was
> > marked as "subscriber local", which is obviously wrong. "Subscriber local"
> > makes little sense when crossing national borders ...
> > 
> > So a quick hack was made to convert these to "international", and it seems
> > that hack carried over into chan_ss7.
> > 
> > So that's the "why" :) Obviously, with chan_ss7 now having reached a much
> > much
> > broader usage, this needs to be fixed. Someone should decide how to expose
> > the "subscriber local" and similar flags to the dialplan, and once that is
> > decided it shouldn't be hard to fix the code...
> > 
> > - Kristian.
> > 
> > -- 
> > _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> > 
> > asterisk-ss7 mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-ss7
> > 
> 
> 



[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux