July 2010 - VoiceOps - lists.voiceops.org

SIP test equipment
by kristian.kielhofner＠gmail.com Sept. 26, 2010

Sept. 26, 2010

Hello everyone, What do you currently use for test equipment? I'm looking for high volume automated testing with statistics and reporting, especially for media (RTP). Just SIP + RTP in our environment, ability to support 2,000 RTP channels minimum with at least MOS (preferably PESQ) scoring. G.729, G,711(u/a), and G.722 (minimum) codec support. Emulated UAS/UAC, gigabit ethernet interfaces, etc. I'm already looking at Ixia IXLoad and Empirix Hammer G5 but I wondered what else people are using... -- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com

5 6

The peer of my peer is my peer?
by David_Hiers＠adp.com Aug. 10, 2010

Aug. 10, 2010

Every so often this issue comes up, and I want to get a read on it from other VOIP resellers... Consider a couple of unrelated VOIP resellers that peer with a carrier like L3. Both can interop with L3 using strict SIP and RTP settings (max forwards, g729 only, 10ms ptime, whatever). Both are free to select mutually incompatible settings. For instance, reseller A can chose 729 only, and reseller B can choose 711 only. L3 will connect both to the PSTN without any trouble. Everything is good until they try to call each other. Then the mutually incompatible settings will break calls or render predicted usage patterns invalid. Sure, you're still signaling to a L3 SIP server, but some the information in the SIP/SDP packets that you receive is controlled by the other reseller. How often do you see problems related to the peer of your peer? David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 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.

9 15

Bad/not unique SIP Call-ID GUIDs
by abalashov＠evaristesys.com Aug. 3, 2010

Aug. 3, 2010

Hi everyone, Am I the only one to run into an unusually high share of duplicate Call-IDs? A SIP Call-ID is supposed to be a GUID (Globally Unique Identifier), and RFC 3261 is quite clear on just how unique it needs to be. From 8.1.1.4: In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call-ID header fields they produce will not be inadvertently generated by any other UA. [...] Use of cryptographically random identifiers (RFC 1750 [12]) in the generation of Call-IDs is RECOMMENDED. Implementations MAY use the form "localid at host". Call-IDs are case-sensitive and are simply compared byte-by-byte. Using cryptographically random identifiers provides some protection against session hijacking and reduces the likelihood of unintentional Call-ID collisions. In theory, this means that no other SIP message series initiated by any other UA anywhere, ever should have that same identifier. In practice, that's a pretty tall order to absolutely logically guarantee by algorithmic means. However, it's certainly possible to get pretty close, from a probabilistic perspective. The use of a highly effective cryptographic digest function coupled with time and/or RTC-seeded pseudorandom values coupled with some sort of host-specific values should result, in the form of a composite, in a very unique value. It is with this understanding in mind that pretty much all CDRs in our least cost routing and other SIP service delivery solutions are keyed off of the Call-ID. The Call-ID is the search key on our CDR tables, and for a variety of logical and performance reasons has a unique constraint on the index. Call-IDs are also used in any situation requiring the organisation of calls into a single-key hash or tree structure of some description. We use them because they're the only "unique" element that conveniently persists across all SIP messages that we would want to logically group together, irrespectively of whether the message is a request, a reply, whether it's an initial or an in-dialog request, etc. They're easy to extract from the message body, and just about anything that operates on SIP messages at a relatively low level exposes some interface by which one can extract the Call-ID. Anything else would rely on implementing an additional, uniform composite hash function of some kind in many different, unrelated software components that all utilise the same database backing, IPC, etc. That's what they're supposed to be used for. Call-IDs are GUIDs, and GUIDs make great keys. Long story short, the problem I've been running into recently is that a surprisingly high number of CDRs generated by certain customers using our solutions are bounced by the database because of Call-ID collisions. I think the quotation from the scrolls above quite clearly spells out that this is singularly the fault of the UACs involved, and while I won't name any names publicly, there are certainly some vendors in particular on whom I have my eye. Nevertheless, it is presenting an accounting problem for us and some of our ITSP customers. I'd be curious to know if anyone else has run into it, and what solutions you may have adopted to deal with it. Thanks! -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

3 4

International DIDs
by jay＠west.net July 29, 2010

July 29, 2010

We are involved with a customer with numerous locations worldwide. Several European countries, Singapore, Australia, China, Brazil, Japan, India. Presently these are all standalone PBX systems. We're considering an integrated VoIP system. Both we and the customer are based in the USA and we're of course familiar with numerous carriers delivering US DIDs via SIP. How are others on the list handling this type of thing? Is there such a thing as number portability and is SIP delivery available in much of the rest of the world? Is there a spreadsheet or list of providers available by country? One thing that looks like it would work more or less universally is to put a gateway in place in each country and continue to get dialtone from each local telco. This seems to be the safest but not necessarily the cheapest. Who has been down this road before? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV

1 0

Malformed ACKs/sequential request lines
by abalashov＠evaristesys.com July 29, 2010

July 29, 2010

[For anyone on Sip-Implementors, sorry for crossposting this here. However, it occurred to me that viewed in a certain light, this could be seen as more of an operational issue than a theoretical one, and I wonder if any of you have encountered it too.] Hi everyone, I am faced with what strikes me as a genuine mystery. In the last few days, I have encountered several completely unrelated commercial SIP UAC implementations that all exhibit the same erroneous behaviour. This behaviour, while certainly incorrect as far as I can tell, is consistent across three or four completely unrelated stacks, leading me to wonder what I am missing. The scenario is that UAC A places call to UAS B through stateful proxy P: A ---> P ---> B P inserts Record-Route header on the initial INVITE in order to stay in the loop on sequential requests. Nothing eccentric in that inherently. When final 200 OK response to the initial INVITE transaction is relayed from P back to A, it contains a normal Contact URI which should be used as the remote target URI for sequential requests (absent any requests that would refresh it): Contact: <sip:xxx at a.b.c.d:5060> It also contains a Record-Route header which has been copied into the reply by B, of course, which looks something like this: Record-Route: <sip:ip.of.proxy.p;lr;param1=blah1;param2=blah2> But bizarrely, the end-to-end ACK sent by A to this 2xx response has a request line formed not from the Contact in the 2xx reply, but from the content of the Record-Route header: ACK sip:ip.of.proxy.p;lr;param1=blah1;param2=blah2 SIP/2.0 Naturally, the proxy is quite bewildered and does not propogate this. 3261 scripture seems quite clear--at least, to me--on why this would be wrong. 12.2.1.1 ("Generating the [in-dialog] Request") says: If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. Other parts of the spec make quite clear that this kind of ACK is an in-dialog request, and that the Contact in the 2xx response establishes the "remote target URI" aforementioned. In other words, pretty commonsensical stuff. I think anyone can agree the request line of the ACK should be: ACK sip:xxx at a.b.c.d:5060 SIP/2.0 However, the fact that I have encountered this in completely unrelated situations with an improbable frequency leads me to believe that there must be some element of this I am failing to grasp. Is it some sort of legacy behaviour and/or RFC 2543 backward compatibility mode that is causing this, or perhaps something else? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

1 1

Passing non-DID/non-BTN CID info on Verizon
by robert.dawson＠mindshift.com July 27, 2010

July 27, 2010

Has anyone been successful in getting Verizon to allow them to spoof CID? We have a customer with around 30 sites in NY - the smaller sites all have POTS lines and failover to a larger regional site with PRI. We are interested in being able to pass the correct CID for the smaller sites when this happens but Verizon is saying it just can't be done. Anyone doing it currently? Thanks, Rob

4 7

NPA 710 GETS NS/EP
by David_Hiers＠adp.com July 23, 2010

July 23, 2010

Hi Group, Is NPA 710 still the federal Government Emergency Telephone Service (GETS) NPA for the National Security / Emergency Preparedness (NS/EP) program? Either someone is misdialing, or pizza hut is calling back to confirm Jack Bauer's order... I figure that something that big couldn't get reassigned without me noticing something in some planning letter, but those GETS folks are pretty tricky :) Thanks, David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 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

Tariff puzzle
by clecny＠gmail.com July 22, 2010

July 22, 2010

Hi Tim, Thanks for your answer, but that raises another question, Why most of the CLEC FCC ( interstate) tariffs include Tandem switching charges? Since most CLECs do not own any Tandem it does not make sense to have these rates included in Tariffs. Also, Will IXC receive two(partial) bills for same call? I am new to this but my telecom attorney told me she has never seen partial bill ( just tandem switching charges ) from a ILEC. I see arguments from both side..still confused :) Regards, Naush. On 7/22/2010 6:04 PM, Tim Jackson wrote: > The ILEC would bill for Tandem Switching to the IXC... > > Usually you see 3 elements, Tandem Switching, Tandem Switching - > Facility (per mou per mile), Tandem Switching - Termination... Some > tariffs combine this, some don't.. Depends on the ILEC's tariff.. > > > -- > Tim > > On Thu, Jul 22, 2010 at 4:06 PM, CLEC NY <clecny at gmail.com > <mailto:clecny at gmail.com>> wrote: > > Hi, > > Pardon me if this is really a dumb question. > > I need to know in following scenario, when call is coming from IXC > location -> CLEC end user ( replace Company with CLEC in picture. > ) Who send bills for "Tandem switching charges" to IXC? CLEC or > ILEC? In this case Tandem switch is owned by ILEC. > > Under switched access servies ,I know CLEC will charge for Common > Trunk Port ( CTP) , Local switching , Local Trunk trasport / > facility , Tandem transport, but Tandem switching is questionable. > > > << picture removed >> > > Sorry about crude picture... > > Thanks & Regards, > Naush. > > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> > https://puck.nether.net/mailman/listinfo/voiceops > >

1 0

Tariff puzzle
by clecny＠gmail.com July 22, 2010

July 22, 2010

Hi, Pardon me if this is really a dumb question. I need to know in following scenario, when call is coming from IXC location -> CLEC end user ( replace Company with CLEC in picture. ) Who send bills for "Tandem switching charges" to IXC? CLEC or ILEC? In this case Tandem switch is owned by ILEC. Under switched access servies ,I know CLEC will charge for Common Trunk Port ( CTP) , Local switching , Local Trunk trasport / facility , Tandem transport, but Tandem switching is questionable. Sorry about crude picture... Thanks & Regards, Naush.

2 1

Contract Development for VOICE PORTAL with Text to Speech
by alramir2020＠gmail.com July 22, 2010

July 22, 2010

Any recommendation for contract developemnt to integrate TTS and ASR into a Call Blaster under Asterisk Al

1 0