- VoiceOps - lists.voiceops.org

SPID parameter in LNP redirects
by abalashov＠evaristesys.com Sept. 20, 2013

Sept. 20, 2013

Hi all, A question for you: do LNP-over-SIP providers--the kinds that return RFC 4694-encoded SIP redirects with the LRN in the 'rn' parameter in the user part of the Contact URI--commonly return the SPID/OCN as well? One major provider we know does; they return a 'spid' on all numbers, regardless of whether 'rn' does. However, others don't return any operator-identifying information at all apart from the LRN. Does anyone have a sense, anecdotally, of how common it is to give back a SPID? Thanks, -- 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/

1 0

WebEx and 1-Way Audio Mid Conference
by scott＠sberkman.net Sept. 20, 2013

Sept. 20, 2013

All, We've been getting a number of reports recently from customers about what they are calling "dropped calls" (thanks Cingular commercials) on WebEx TF conference lines, meaning they lose an audio path mid-call. This usually impacts only the one caller (other callers on the bridge are apparently not impacted) and we're getting these reports for calls traversing a variety of termination carriers with not much of anything else in common. Anyone else getting similar reports or dealt with something similar with WebEx? Thanks, -Scott

2 1

Major carriers and odd T.38 behavior
by lindsey＠e-c-group.com Sept. 19, 2013

Sept. 19, 2013

I've recently bumped into some odd restrictions with the largish (nationwide, incumbent LEC) Sonus-based SIP carriers, such as: (a) Carrier Restriction: If g711u is the preferred codec in a call, then the call will never be re-invited to T.38. Implication: Any call from a line that could be connected to a fax machine cannot be started with G.711 as the preferred codec. (b) Carrier Restriction: The SIP carrier will never send the T.38 re-INVITE, even if the call is going to the SIP Carrier. Implication: I have to use SIP-POTS gateways (ATAs, IADs) that are able to re-INVITE to T.38 when they originate the call, while many ATAs/IADs would expect the receiving T.38 device to do the re-INVITE. It seems like these implications limit the options available for ATAs and IADs, and the intended use of codecs for commercial lines that may carry both voice and fax. Has anyone successfully worked through it all? On Jan 10, 2012, at 1:15, Ryan Delgrosso <ryandelgrosso at gmail.com> wrote: > I have seen numerous scenarios where a softswitch acting as a forking proxy will use a dummy SDP in its outgoing invite (Metaswitch and Sylantro both come to mind here), and immediately will re-invite when the far end has answered. > > I have also seen numerous scenarios where fax servers will send the initial invite with G711 and then instantly re-invite to T.38 upon answer. > > Dont stand on convention or BCP here, the re-invite often comes from the calling party, and sometimes a few times. > > On 01/04/2012 06:46 AM, Mark R Lindsey wrote: >> The IETF informational draft: "SIP Support for Real-time Fax: Call Flow Examples And Best Current Practices" shows the re-INVITEs from the called party. This is still conventional best practice. >> >> http://tools.ietf.org/html/draft-ietf-sipping-realtimefax-01 >> >> >> Mike Coffee's talk at SIPNOC 2011 discussed the expectations, showed how things can fall apart: >> >> http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,115/I… >> >> >> -- Mark R Lindsey mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey >> >> >> >> >> On Jan 4, 2012, at 04:35 , Nathan Anderson wrote: >> >>> This might not be the most appropriate forum for such a question, but given that implementation bugs in either NOC gear or CPE gear can cause headaches for network operators, I offer this here in the hope that perhaps a fellow VoiceOp here may have run into this before and knows the answer... >>> >>> It is my understanding that with SIP, *either* party to a call can send another INVITE (a so-called "re-invite") at any time during an active session; this could be used to change the endpoint of a call or redirect it elsewhere, and is also commonly used to renegotiate the media in use (audio, video, image, and associated codecs) without dropping the call even while the endpoints remain the same. >>> >>> Does this hold true, though, for re-invites whose purpose is to switch from an RTP audio stream to a T.38 UDPTL stream? Can *either* peer send that INVITE? Or is there a rule -- spoken or unspoken -- that states that a T.38 re-invite can only be initiated by the *receiver* of the fax, and not the transmitter? >>> >>> I have some ATAs that appear to send out a T.38 re-invite upon detection of a fax tone regardless of whether the ATA placed the call or answered the call, and if I am understanding what I'm seeing in my packet captures, I think the fact that these ATAs do this even when they are going to play the role of the T.38 transmitter is confusing the heck out of my (Asterisk) SBC and the termination provider. But I can't find any concrete evidence to support the idea that T.38 re-invites should only be initiated by the receiver.

3 2

test
by jaredball1＠gmail.com Sept. 19, 2013

Sept. 19, 2013

test

3 2

Verizon T.38
by Jared.Ball＠adp.com Sept. 19, 2013

Sept. 19, 2013

Does anyone have an experience with T.38 Interoperability with Verizon? I have eight different telephone numbers in different area codes \ prefixes. Some re-invite T.38 and other re-invite G.711 only. I've done multiple tests on these numbers with consistent results. Bad numbers: 412-469-02XX 412-469-40XX 615-850-XXXX 858-693-XXXX Good numbers: 503-205-02XX 858-695-XXXX 502-205-01XX I have a trouble ticket open with Verizon. I can tell from the SIP signaling that they are using Sonus but it isn't clear whether their configuration and support for T.38 is uniform across their platform. Is Verizon's support for T.38 usually consistent? I have a Ditech PVP that I can use for transcoding. Should I just assume that I'll need to transcode some of the time? My Fax Server is T.38 only and will rejects calls with "488 Not acceptable here". My Ditech PVP is end of life so if transcoding is a requirement I may be looking for a new transcoding solution. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

1 0

Verizon T.38
by jaredball1＠gmail.com Sept. 19, 2013

Sept. 19, 2013

Does anyone have an experience with T.38 Interoperability with Verizon? I have eight different telephone numbers in different area codes \ prefixes. Some re-invite T.38 and other re-invite G.711 only. I've done multiple tests with consistent results. Bad numbers: 412-469-02XX 412-469-40XX 615-850-XXXX 858-693-XXXX Good numbers: 503-205-02XX 858-695-XXXX 502-205-01XX I have a trouble ticket open with Verizon. I can tell from the SIP signalling that they are using Sonus but it isn't clear whether their configuration and support for T.38 is uniform across their platform. Is Verizon's support for T.38 usually consistent? I have a Ditech PVP that I can use for transcoding. Should I just assume that I'll need to transcode some of the time? My Fax Server is T.38 only and will rejects calls with "488 Not acceptable here". My Ditech PVP is end of life so if transcoding is a requirement I may be looking for a new transcoding solution.

1 0

test
by David.Hiers＠adp.com Sept. 19, 2013

Sept. 19, 2013

test David This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

5 5

Homegrown SIP load testing platform
by jchleboun＠e-c-group.com Aug. 31, 2013

Aug. 31, 2013

I am interested to see if y'all have recommendations for putting together a SIP load testing platform using general purpose hardware and open-source (or inexpensive) software. We are aware of Empirix Hammer and similar solutions, and we are looking to see if there is an alternative option. Goals: - Generate somewhere on the order of 20k phone calls with real SIP and RTP. - Route the flows through our VoIP infrastructure to test performance limits. - Receive and analyze the SIP and RTP on the other end to find out at what load the signaling and/or media start to break down. Attempted already: - SIPp spread across many servers. Here the limiting factor seemed to be the CPU load from the interrupts from each packet. The CPU on the servers sending and receiving the phone calls got bogged down before the VoIP core. - We have dabbled with interrupt moderation in the NIC drivers, but this has not seemed to help very much. Looks interesting: - Has anyone had success using PF_RING with Direct NIC Access and libzero from the folks at ntop? Has anyone been able to use this with SIPp or some other SIP and RTP generator? Many thanks, Jon Chleboun

2 1

SIP Router
by David.Hiers＠adp.com Aug. 16, 2013

Aug. 16, 2013

Hi, I need a SIP router to steer calls though our core. All its going to do is redirect calls by sending 3xx responses to every INVITE. What do you think of Kamailio? Does it play well with Broadsoft and Acme? Have you seen any better freeware out there? Thanks, David This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

3 2

GRE
by bobhancock205＠gmail.com Aug. 14, 2013

Aug. 14, 2013

I have a project in which a user is interesting in interconnecting and deploying ATAs for VoIP services but wants to use private IP addressing on the devices. My initial though is to NAT these devices and allow my SBC to handle NAT traversal for them. This allows the to use their dedicated connection to my network or if that link goes down fail over to moving to connecting across the internet. They are interested in potentially doing a GRE tunnel and keeping the private addressing in place as it traverses that tunnel. I am concerned about encapsulating the VoIP traffic as well as with the fail over options. Does anybody have any experiences with VoIP over GRE tunnels and what type of results and challenges you encountered? Thanks. --BH

3 2