- VoiceOps - lists.voiceops.org

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

March 21, 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 19, 2013

March 19, 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

Cisco 79xx Phones Running SIP and DNS SRV
by zak＠simplesignal.com March 12, 2013

March 12, 2013

Hello- Is anyone out there using Cisco 79xx phones with DNS SRV? I am struggling and due to Cisco not supporting the SIP loads now it?s very hard to find info or insight. Let me know if you?re willing to share please J Zak Rupas Tier 3 Voice Engineer IP Phone/Text Msg: +13032428606 Like SimpleSignal on *Facebook* <http://www.facebook.com/SimpleSignal>* !* SimpleSignal Inc.

1 0

Call quality issue / survey
by nathana＠fsr.com March 11, 2013

March 11, 2013

Hey gang, Let's play a game. I have made two audio rips from two RTP captures I made of two phone calls through two different termination carriers to the same phone number (in this case, it happens to be to the IVR at City Hall of Fairbanks, AK). I have temporarily allocated 2 DIDs for the purpose of this game, and depending on which one you call, you will either hear played back to you the recording of the call as it happened through one carrier, or through the other. Whoever wants to participate, please place calls to both numbers (do it either from a landline or a G.711u VoIP session, please), and tell me which version of the recording you prefer, why you prefer it, and if you had to put it into words (which you do), how you would describe the difference between the two recordings. I am not going to tell you which one I prefer nor which carrier terminated which recording (I'm actually not 100% sure yet in the case of one of them), or even which carriers are involved, at least until after I've gotten some feedback from you all first. Basically, I'm trying to find out if I'm crazy, or if there really is a difference between the two recordings in terms of audio quality. I say there is a stark difference. I've had others tell me they can't hear it. Maybe I have "golden ears". :-P Here are the two phone numbers to call: 208-301-5083 208-301-5084 Alternatively, for those of you would like copies of the actual audio files to listen to, I can provide those upon request; just contact me off-list. Thanks, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

6 13

Call quality issue / survey
by nick＠flhsi.com March 11, 2013

March 11, 2013

This was my experience as well. 5083 is better. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Gabriel Gunderson" <gabe at gundy.org> Sent: Friday, March 08, 2013 9:29 PM To: "Nathan Anderson" <nathana at fsr.com> Cc: "voiceops at voiceops.org" <voiceops at voiceops.org> Subject: Re: [VoiceOps] Call quality issue / survey On Fri, Mar 8, 2013 at 6:55 PM, Nathan Anderson <nathana at fsr.com> wrote: Calls placed from XO eSIP and AT&T cell, exact same results: > 208-301-5083 :00 No ringback :01.5 Music starts :03 Silence and then woman speaking on the IVR. Consistent volume > 208-301-5084 :00 No ringback :07 Loud click :10 Her voice is very weak and fades in (and is somewhat choppy) :12 Normal from that point forward 208-301-5083 is far and away better. Sounds better, starts quicker, no awkward silence. What do I win for playing? Best, Gabe _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0

VoIP traffic survey
by frnkblk＠iname.com March 9, 2013

March 9, 2013

I've been asked to address some of the technical matters of the VoIP at a regulatory-oriented meeting, but not being a consultant my knowledge and experience aren't as broad as they should be. One of the concerns by RLECs related to AT&T (and Verizon's) de-regulation initiative is compensation for origination and termination of traffic. Today many non-pricecap rural carriers are paid by IXCs both for any traffic originated or terminated from the network. Most, if not all, of that compensated traffic, is originated as TDM. The concern is that if the rural carriers move to IP that they won't be paid (hardly) anything for origination or termination. Discussions are being held to use ETS (Ethernet Transport Service) and other NECA-type approach to facilitate a way for RLECs to bill for originating and terminating traffic in an IP-world. These private connections, with QoS support, would allow for both capacity and perhaps volume-type billing. But it's been my experience that much of the VoIP long-distance traffic flows over the Internet, not over private Ethernet circuits. My question to this group, which is very IP heavy and therefore much ahead of the curve in terms of IP-oriented telco operations, is how much traffic flows over public (i.e. Internet) circuits versus private (point-to-point to another carrier or VoIP exchange) circuits, and also how that compares inbound versus outbound. http://www.surveymonkey.com/s/6PRCGWM Any additional commentary on this forum would be help. Regards, Frank

2 4