- VoiceOps - lists.voiceops.org

+44 190 prefix
by abalashov＠evaristesys.com March 24, 2013

March 24, 2013

A customer of mine is seeing aggressive attempts to dial +441904891769 through their system, but I can't find +44 190, or any superset or subset thereof (beyond '44', obviously) in any rate decks easily at my disposal. None of the usual retail suspects have it listed in any of their online pricing, either. I assume this means it's a new prefix, but can anyone tell if it's a premium number? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

7 9

Older Cisco SIP firmware download
by abaird＠telesphere.com March 23, 2013

March 23, 2013

Hi all. I have been tasked with performing a SIP interop with the Cisco 7941 model IP phone. I've failed to get it working with the latest SIP 9.x which is still available from Cisco w/o a contract. >From what I've found in my research, an older version 8.5.4 might be the way to go but I can't download it from Cisco without a contract. I'm not sure why they chose to protect the older versions but not the newer. Anyway, would any of you happen to know an alternate place for me to download the file? I'm not sure I'll be able to purchase a contract to allow me to download the file since this model went EOS so long ago. I'm looking for: cmterm-7941_7961-sip.8-5-4.zip Feel free to direct message me if you prefer. Thanks -Adam

17 27

Call Forwarding is broken; or, when CF meets LCR
by nathana＠fsr.com March 21, 2013

March 21, 2013

On Monday, March 18, 2013 12:40 PM, Mike Ray <> wrote: > Many factors went into our decision on how to handle these situations. > Regulation is one of those; it is illegal to stuff the ANI to change the > jurisdiction of the call although we know that many carriers/ITSPs do that > anyway. Perhaps this is splitting hairs (and I admittedly have not read the actual language of the law(s) you are citing), but I would argue that in my example, if I were to "stuff" the ANI in the way I describe (take called party/forwarder's number and use that for ANI), I wouldn't be doing so to necessarily change the jurisdiction of the call to be in my favor; there would be scenarios in which it would be advantageous for me from a billing perspective to *not* do that. I would, in fact, be doing it to actually set the *correct* jurisdiction of that leg of the call, regardless of whether it happens to be in my favor or not. Using the caller's ANI as ANI for the forwarded leg is causing the *incorrect* jurisdiction to be selected, but is the only way to get the correct Caller-ID passed through end-to-end. *That* is the frustrating part. > However, as you noted, if you stuff the ANI it will negatively > affect your customer's perception of your service, since that is not how a > PSTN forward would be handled. Thus, a disincentive to me and other reputable ITSPs to engage in such activity. > The real issue is that the PSTN, both at the SS7 and PRI signalling > levels, recognizes both the ANI and the BillingNumber fields for any call > but SIP does not have that construct. The "PSTN-proper" way to handle > this would be to pass the original caller's ANI for CallerID, but to pass > your forwarded customer's BillingNumber. However, SIP just has ANI and > that's it. Actually, as I understand it, PSTN doesn't "automatically" pass the caller's ANI for CNID, which is another reason to consider the "industry-standard" methods of SIP->SS7 interop to be broken. There are, to my knowledge, *three* separate fields: 1) CNID 2) ANI 3) BTN (Then there is also ANI2, but that's not terribly relevant to this discussion, I don't think.) I have also heard #2 and #3 referred to as "ANI" and "Charge ANI" respectively. What I have never quite understood is what the relationship between the two are, and if someone could explain that, I would be grateful. However, I am quite sure that CNID does *not* have to match ANI, and I would be quite content if, instead of adding a new field to the SIP header for BTN (leaving CNID+ANI the way it is now), ANI+BTN were instead combined, CNID was split out into its own thing, and new field was added instead for either CNID or ANI+BIN. (Of course, ultimately, it would be best for all 3 to be separate if that is how they are signalled on SS7.) > So the way we decided to handle this in the final analysis is that we > already bill our wholesale ITSP subscribers for outbound calls on two > levels: one for local and the other for non-local. We use the actual ANI > of the calling party to determine this jurisdiction (local/non-local) > because that is what will trigger the terminating carrier's access > billing to us, and we bill our ITSP customer the proper rate based upon > that, regardless of the forwarding-customer's number. Right, and that's how everybody seems to be doing it. But, again, the problem I'm pointing out is that using the calling party's number to determine this juristiction is horribly broken and wrong, IMO. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

3 4

711 relay
by brandon＠kamikos.com March 20, 2013

March 20, 2013

We used 933 to verify 911 info, leaving 811 for OneCall utility locates. Carlos Alvarez <carlos at televolve.com> wrote: >On Wed, Mar 20, 2013 at 7:12 PM, Mike Ray <mike at astrocompanies.com> wrote: > >> Are you sure that your CLEC provider isn't doing this for you? We do. >> CLECs are required to provide this service, and the translations happen in >> our switch when you send us an x11 call. So you shouldn't have to do >> anything. >> > >I can tell you that if we send 811 to Vitelity, they just read back our >CID. We, and they, use this for testing 911 systems. We have the >customers dial 811 to verify the 911 CID is right. Which in light of >today's conversation is clearly not legal, though arguably far more useful >than having someone come out and mark utility lines. > >I have not tried sending 711 to any of our carriers. They are all >SIP-based and I have no idea how they will handle it, but I'm going to try >it. > >-- >Carlos Alvarez >TelEvolve >602-889-3003 > >_______________________________________________ >VoiceOps mailing list >VoiceOps at voiceops.org >https://puck.nether.net/mailman/listinfo/voiceops

1 0

711 relay
by nathana＠fsr.com March 20, 2013

March 20, 2013

Question for other ITSPs out there: what are you doing for 711 TTY relay services? I know so little about this area it's sad. Are we supposed to either staff our own relay staff, pass them off to a third-party relay service, or pass the calls off to a state-provided service? Can this be done with a third-party service a-la what 911Enable and friends do for 911 PSAP routing? What companies out there provide services like this? If the states you provide service in have an 800 number for connecting to a state-run relay service, can I simply translate 711 to the appropriate 800 number and terminate the 800 call as I normally would? Thanks, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

9 19

Older Cisco SIP firmware download
by mm＠42com.com March 19, 2013

March 19, 2013

Google: inurl:cmterm-7941_7961-sip.8-5-4.zip But its a russian site, not sure if this is legit? Best Regards On 03/18/2013 11:37 PM, Adam Baird wrote: > Hi all. > > I have been tasked with performing a SIP interop with the Cisco 7941 > model IP phone. I've failed to get it working with the latest SIP 9.x > which is still available from Cisco w/o a contract. > > From what I've found in my research, an older version 8.5.4 might be > the way to go but I can't download it from Cisco without a contract. > I'm not sure why they chose to protect the older versions but not the > newer. > > Anyway, would any of you happen to know an alternate place for me to > download the file? I'm not sure I'll be able to purchase a contract > to allow me to download the file since this model went EOS so long ago. > > I'm looking for: cmterm-7941_7961-sip.8-5-4.zip > > Feel free to direct message me if you prefer. > > Thanks > -Adam > > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops

4 5

Call Forwarding is broken; or, when CF meets LCR
by nathana＠fsr.com March 18, 2013

March 18, 2013

On Monday, March 18, 2013 4:50 PM, Nathan Anderson <nathana at fsr.com> wrote: > Right, and that's how everybody seems to be doing it. But, again, the > problem I'm pointing out is that using the calling party's number to > determine this juristiction is horribly broken and wrong, IMO. I'm responding to myself in order to clarify that I mean doing so is "horribly broken and wrong" specifically in the scenario we are talking about: PSTN call forwarding. The way you describe is, of course, the correct way to do things in the case where the calling party is our customer, and they are making a direct call out themselves. -- Nathan

1 0

Call Forwarding is broken; or, when CF meets LCR
by nathana＠fsr.com March 18, 2013

March 18, 2013

(Maybe there is a better place to discuss this, like SIPForum or SIP-Implementors, but because of the chance that there is something I'm missing here, I decided to float this by y'all first for feedback. BTW, I'd also LOVE any input from various carriers & termination providers that might be subscribed to this list...perhaps you have implemented solutions of your own to this problem that I am unaware of.) So, I got to thinking about call forwarding recently, and how it seems to me that CF, specifically at the point where IP meets PSTN (such as with interconnected VoIP providers like ourselves), is inherently broken. (Although it could also be argued that the PSTN itself is inherently broken, being filled with layers of legacy cruft and overly burdened with decades of bass-ackwards regulation, but I digress.) Allow me to explain. In pure IP land, because SIP endpoints have intelligence and are not mere dumb terminals, CF is easy. If the target peer is set to divert calls elsewhere, it can just signal back to the calling party (typically using SIP 3xx response codes) what address it should, in fact, be calling instead to reach this user, and it's then up to the caller's user agent to directly INVITE the forwarding target. Or if a call transfer is desired after media is already established between peers, REFER is used to cause the transferee to generate a new direct INVITE to the transfer target. The end result in either case is that the responsibility for ultimately taking the *action* needed to forward or transfer a call belongs to the original caller or transferee, *not* the callee or transferor. The caller/transferee's endpoint simply uses signalling information it's been given to, in essence, hang up the existing call and then place a new call to the new target. In the PSTN, things are more complicated due to billing issues, as well as due to the fact that by-and-large the intelligence is all in the switching infrastructure instead of the handsets, but overall it's still pretty simple to understand. As I understand it, a call forward is really, at its most basic level, the hairpinning of a call within the target switch. Neither the caller nor the caller's switch even need know that a call forward was requested or is occurring. This is only fair when you think about it: since the caller pays for the call, it wouldn't be good if a call forward on the PSTN caused the caller's switch to blindly divert the call elsewhere upon instruction from a remote switch without the caller's consent, since this could potentially lead to the caller paying a higher rate for the call than he/she assumed the rate would be based on the originally dialed number (for example, if the caller dialed a local number that was in turn set to forward to a number on the other side of the country). So, typically, the callee who put the call forward in place picks up the tab on the forwarded leg of the call. Now, as an interconnected VoIP provider which gives their users the option of configuring their account to forward to off-network numbers, this is the problem we face: as far as I am aware or have been able to determine (and I hope I'm wrong/missing something), most SIP-based termination providers blend ANI and Calling Number ID together. They'll either use PAI as the ANI/CNID, or, if PAI isn't present, use From. But both ANI and CNID for that call will be determined by a single parameter, and so will always match each other. Why is that a problem? Well, since we are interconnected to the PSTN, we can't just pass back any SIP 3xx responses we get to the carrier during call set-up and expect them to just deal with it for us and bill us appropriately, or in the case where the call forward is set on our side and our customer's endpoint is never even sent an INVITE, we can't generate a SIP 3xx response to the originating carrier ourselves. (I suppose if we used the same carrier for origination and termination, it might be an option to send back SIP 3xx to them as a response to an incoming INVITE, but I'm not sure how most carriers would deal with or respond to that...I imagine it varies. But we use different carriers for origination and termination anyway, so that's not even an option "in theory.") To forward off-net, we have to generate a second call leg ourselves by INVITEing out through our term provider, and then bridging the two calls. When we do this, we are faced with a decision: what do we use as ANI/CNID for the forwarded call? Since we can't specify both ANI and CNID separately, we are forced to choose one number to represet both. The problem is that there are really only two options, and neither option does exactly the right thing. Our first option is to stuff my subscriber's number -- the dialed TN (DNIS) -- into PAI and From, but then the phone being forwarded to would not show the number of the actual caller to the recipient, and I think most people want and EXPECT their phone to always show them the caller's CNID, and not the number that is being billed for the forwarding (although perhaps some people might find it helpful to know whether the person calling was redirected to this phone and from where, or whether the caller dialed this phone directly). The second option is to stuff the caller's CNID into PAI and From, which would display the right thing on the phone at the end of the forwarding chain. However, there is a huge problem with this! The term network bases their routing/LCR decisions on these fields, and the rate that is charged for the call is also based on these fields. So even though the callee that put the forward in place is picking up the tab on this leg of the call, the call is being BILLED and ROUTED based on the CALLER'S Caller-ID, NOT based on my subscriber's ANI! This is wrong, wrong, wrong! What happens if one of my subscribers has a forward in place on his main TN to a number outside of his LATA, and someone from within the LATA of the number he is forwarding to calls his main TN? I get dinged for an intraLATA call that *should* have been classified as interLATA, that's what! We need some way of being able to signal ANI and CNID *separately* to SIP->PSTN termination providers, so that the call is routed properly AND the correct Caller-ID number shows up on the final telephone at the end of the chain. You shouldn't have to pick between the two; native PSTN calls don't. As far as I can tell, there is no standard way of doing this. I have even run some experiments, and so far have not been able to make a correct educated guess about how some of these providers *might* have decided to implement such a feature on their side (whether documented or undocumented), assuming that any of them have. Here are two options that I thought might be reasonable enough to try: 1) PAI is an optional SIP header field; if it is present and does not match From, perhaps From should be used as CNID, and PAI as ANI. In my experience, SIP term providers typically only consult From as a last resort if PAI is not present; if it is, From is ignored completely. I haven't found an example of one that honors both fields in this way. 2) When a call forward occurs on the PSTN, RDNIS/RGN (forwarding number) is typically included in the SS7 signalling at the final switch. There are a couple of SIP header fields that people have conjured up to fill a similar role: Diversion (which was described in an IEFT draft and has seemingly become a "de facto" standard of sorts, much like Remote-Party-ID was before PAI arrived), and History-Info (which actually made it into an RFC, 4244). Perhaps, in the event of a forwarded call, it would make sense for term providers to use Diversion or History-Info to inform them of what to use as ANI. I attempted to send calls out with one field or the other included in the header, but it made no difference: either PAI (if present) or From (if PAI not present) continued to be used as the sole source for both ANI and CNID. Am I missing something here? Is there a standard way of doing this (or at least a not-exactly-standard-but-generally-accepted way)? Or is this really something that nobody has paid the attention that (I would argue) it's due? Thanks for any suggestions or feedback you may have. Regards, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

2 2

Call Forwarding is broken; or, when CF meets LCR
by nathana＠fsr.com March 18, 2013

March 18, 2013

On Monday, March 18, 2013 12:20 PM, Lee Riemer <mailto:LRiemer at bestline.net> wrote: > Diversion header? I already tried that: > On Saturday, March 16, 2013 1:29 AM, Nathan Anderson <> wrote: > > > 2) When a call forward occurs on the PSTN, RDNIS/RGN (forwarding number) > > is typically included in the SS7 signalling at the final switch. There > > are a couple of SIP header fields that people have conjured up to fill a > > similar role: Diversion (which was described in an IEFT draft and has > > seemingly become a "de facto" standard of sorts, much like > > Remote-Party-ID was before PAI arrived), and History-Info (which actually > > made it into an RFC, 4244). Perhaps, in the event of a forwarded call, > > it would make sense for term providers to use Diversion or History-Info > > to inform them of what to use as ANI. I attempted to send calls out with > > one field or the other included in the header, but it made no difference: > > either PAI (if present) or From (if PAI not present) continued to be used > > as the sole source for both ANI and CNID. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

1 0

Verizon Business Outage?
by peeip989＠gmail.com March 13, 2013

March 13, 2013

All our gateway connections to VZ dropped about 15 minutes ago. Anyone else seeing this?

4 8