[VoIP] Number portability in CNET

Tue Oct 30 02:57:55 CST 2007

Thanks Shane that helps solidify it for me.

Dennis

-----voip-bounces at ckts.info wrote: -----

To: voip at ckts.info
From: Shane Young <voiptandem at shaneyoung.com>
Sent by: voip-bounces at ckts.info
Date: 10/27/2007 05:47PM
Subject: Re: [VoIP] Number portability in CNET

Frequently the answer with Asterisk is "yes".

Either way can work.

A: Call comes from switch-a to switch-b which makes a call to
switch-c.  The payload stays up through all of the switches.

B: Call comes from switch-a to switch-b which makes a call to
switch-c.  Once switch-c answers, the payload is released to direct
from switch-a to switch-c.

Previously with IAX, once switch-b was out of the loop, they knew
nothing more about the call.  Newer versions of asterisk (1.4.x I
think) now support releasing just the audio to the calling and
destination endpoints, keeping the signalling up all the way thrgouh.
In other applications outside of CNET, this is required for billing.

I had a pseudo "calling card" application I built for a friend of
mine.  His system sat at home on his dsl connection.  The callers
would dial an 800 number which would come into his system.  he'd
authenticate them and get the number they wanted to call, place the
call to that party.  Once they answered, the whole thing went direct
between the calling carrier and called carrier, but he got no
length-of-call records.

SIP get's more tricky as it uses another protocol for the audio (RTP)
and it's famously picky with NAT/PAT in the loop.

Quoting Dennis D Hock <hockd at dteenergy.com>:

>
> Steph,
>
> I was under the impression with my limited education on this that all
that
> was being redirected was the address duroing the initial setup.  It would
> not be quite like legacy tandeming.  Once the request was recognized to
no
> longer be within the far end * box, it would send the new location of
that
> number back and the first * box would then simply redirect to that
tandem.
> I would'nt see any additional delay per see as long as they redirecting
> party was not trying to perform legacy tandeming.
>
> Greg / Shane am I correct in this assumption?
>
> Dennis H.
>
> -----voip-bounces at ckts.info wrote: -----
>
>
> To: Voice Over IP Tandem for Analog Switches <voip at ckts.info>
> From: Steph Kerman <stfkerman at jps.net>
> Sent by: voip-bounces at ckts.info
> Date: 10/27/2007 12:52PM
> Subject: Re: [VoIP] Number portability in CNET
>
>
> David Josephson wrote:
>> As with most software-defined realities, we can do any or all of those
>> things. The whole 7-digit dialed number is part of the ENUM query, so
>> Greg's server could indeed look up each individual number, or look for
>> ranges of numbers.
>> I should have written more of a preface. I was responding to the
>> latest round about office code hoarding.
> It would be interesting to see an inventory of how many office codes
> have been taken, how many of those have been activated and how many are
> open.  It sounds like the whole topic is not a real concern for the
> foreseeable future considering the ease with which the existing ENUM
> structure supports sharing with very high flexibility in the block size.
>> Since this topic comes up tiresomely often, implying that someone
>> would like one of the office codes that someone else is sitting on, we
>> could reach a consensus that we'd ask Greg to carve out some of the
>> office code in the ENUM table, if the original assignee of that office
>> code was not using it, and/or unable to forward a desired number to
>> someone who *would* use it.
> Here's where you lose me.  I don't understand the distinction you are
> making between carving out a block or individual number in ENUM and the
> original assignee "forwarding" it.
>> Whether the call is forwarded by redirect or by tandem switching of
>> course depends on the architecture of the two involved offices.
> I understood Shane to be saying that redirection occurred through ENUM.
> What mechanism exists for a call to be forwarded by redirection other
> than through ENUM?  Tandem switching seems likely to increase the delay
> to an intolerable point.  I don't see how it can not introduce
> noticeable unnecessary impairment even if some might consider the total
> delay acceptable.  Has anyone experimented with tandem switching through
> CNET to see what the calls sound like?
>
> Steph
>>
>> David Josephson
>>> How does this fit in with David's comment?
>>>
>>> If the full 7-digit number is looked up in ENUM for each call to
>>> allow sharing of office codes doesn't that require ENUM to be updated
>>> for all new line assignments at local switches? I thought only the
>>> 3-digit office code was being looked up and that there was discussion
>>> about extending this to the thousands digit to allow sharing of
>>> office codes in blocks of 1000 numbers, but that it had not been done.
>>>
>>> Steph
>>>
>>> Shane Young wrote:
>>>
>>>> There is no need to do either.
>>>>
>>>> Since we always lookup every number in DNS via ENUM, greg just
>>>> points the "ported" number to the new destination.
>>>>
>>>> It's a lot like the way real LNP works.
>>>> --Shane
>>>>
>>>>
>>>> Quoting Steph Kerman <stfkerman at jps.net>:
>>>>
>>>>
>>>>
>>>>> Send by redirecting at the originating point or send by tandeming
>>>>> through your system?
>>>>>
>>>>> Steph
>>>>>
>>>>> David Josephson wrote:
>>>>>
>>>>>
>>>>>> I think that anyone who has an office code should be able to
>>>>>> provide routing to other CNET numbers, should anyone else have a
>>>>>> desire for a
>>
>>
> _______________________________________________
> VoIP mailing list
> VoIP at ckts.info
> http://lists.ckts.info/mailman/listinfo/voip
> Project Web Page: http://www.ckts.info/
> _______________________________________________
> VoIP mailing list
> VoIP at ckts.info
> http://lists.ckts.info/mailman/listinfo/voip
> Project Web Page: http://www.ckts.info/
>

--Shane
+1-821-7311 CNET

----------------------------------------------------------------

_______________________________________________
VoIP mailing list
VoIP at ckts.info
http://lists.ckts.info/mailman/listinfo/voip
Project Web Page: http://www.ckts.info/