Telecom PTC - SIP Trunking

Forums › VoIP › Telecom PTC - SIP Trunking

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#55453 4-Jan-2010 21:24

For those who are interested Telecom's new PTC for SIP trunking appeared on the Telepermit site before Xmas.

http://www.telepermit.co.nz/PTC228_2009draft.pdf

This details the requirements for interconnection with Telecom's SIP trunking service that will be rolled out this year.

1 | 2

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#287013 4-Jan-2010 21:42

Interesting to see Telecom requiring '1' to be used as an escape code and that it must be sent in the TO: field in the SIP URI.

Escape codes are something that are now obsolete with SIP - they're a legacy feature that isn't needed in the world now. Even if they are used Telecom requiring the 1 to be sent as part of the TO: field is very strange.

Does anybody know why this requirement is in there?

savag3

188 posts

Master Geek
+1 received by user: 3

#287026 4-Jan-2010 22:23

Maybe the 1 is used becuase the SIP trunks are built on their Centrex platform (1 is the number used in front of calls on Centrex lines). Just guessing though.

bender

220 posts

Master Geek
+1 received by user: 17

#287040 4-Jan-2010 22:57

T.38 not supported and G711a only?! Why is a NTU required on the customer end too? Isn't that just introducing unnecessary cost? They could do just as well with separate VLAN's since (from the doc) it's delivered over Ethernet.

And yes, requiring 1 on outbound calls is silly, they should use E.164 format because then it doesn't break stuff when the customer wants to either use multiple SIP providers for redundancy or route calls differently - it will just complicate things when the customer has to have a zillion rules on their side to change number formatting.

Ignoring privacy headers too?

I hope this is very much a draft and that Telecom will reconsider some of the specifications to get in-line with the standards they talk so heavily of in the document...

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#287051 4-Jan-2010 23:39

I was surprised to see G711a only support as well. G.722 support should be included, IMHO HD voice is going to be a key selling point for VoIP solutions for many people in the not too distant future.

Lack of T.38 is surprising but G711 passthru does work extremely well and T.38 can still be hit and miss and not all T.38 support is created equal. Telecom's backend systems are extremely well engineered and I can see fax passthru working extremely well, especially when the last mile is also going to be over a dedicated connection.

bender

220 posts

Master Geek
+1 received by user: 17

#287053 4-Jan-2010 23:47

Yes, all systems I manage have G722 turned on and customers do pass the odd comment when they reach someone else on G722 that "wow that call sounded amazing".

I am surprised ulaw isn't permitted though, without this you won't be able to have end to end IP calls to other providers be it in NZ or in countries like the USA.

T.38 is necessary for reliable faxing, while G711 will work under perfect conditions and might work if Telecom are only feeding you IP to their core, it will creat issues when they do talk IP to other providers where longer distance IP networks are involved and packet loss or latency becomes an issue. Even if Telecom aren't planning to talk SIP externally to other providers, eventually they will have to, and at that time would be far better off requiring PBXs to at least support T.38 passthrough.

bender

220 posts

Master Geek
+1 received by user: 17

#287057 4-Jan-2010 23:59

Also just gave it some more thought, Cisco Unity/Unity Express are ulaw only, so if you connected Call Manager/Express to Telecom SIP it would require transcoding for Auto Attendants and Voicemail... Ew. Given this product is aimed at Enterprise by the looks of things, the volume of calls to voicemail and auto attendants is potentially huge, so DSP requirements would be rather high, ignoring the fact transcoded calls are yucky.

They definitely need to review their spec.

New World

Shop on-line at New World now for your groceries (affiliate link).

savag3

188 posts

Master Geek
+1 received by user: 3

#287061 5-Jan-2010 02:35

@bender: Cisco 7940/60 phones in SCCP mode at least are also ulaw only. Which means you would need to use something like Cisco Unified Border Element with enough DSP's for however many SIP channels you have from Telecom. Pretty expensive.

savag3

188 posts

Master Geek
+1 received by user: 3

#287062 5-Jan-2010 02:38

The biggest problem is probably ignoring privacy headers. This means in order to withhold CLI for an extension you will have to use (at least in Cisco UCM) partitions and translation patterns to add 0197 to each call dialed from that phone. Yuck.

savag3

188 posts

Master Geek
+1 received by user: 3

#287063 5-Jan-2010 02:44

After a bit more thought I honestly can't see any advantages to using Telecom's SIP trunking compared to ISDN PRI. At least not with the spec in its current state. You might save $1k for the PRI card and thats about it.

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#287073 5-Jan-2010 06:47

savag3: After a bit more thought I honestly can't see any advantages to using Telecom's SIP trunking compared to ISDN PRI. At least not with the spec in its current state. You might save $1k for the PRI card and thats about it.

There may not be any advantages at present but that ignores the fact PRI's are end of line and will eventually become obsolete. My understanding is that Telecom have no plans to deploy ISDN on their ALU ISAM's when they are eventually deployed to replace the NEAX switches.

If this infact true (and it's certainly my understanding) then it's going to be an expensive upgrade path for many people who are tied to ISDN still in 8+ years time.

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#287074 5-Jan-2010 06:53

bender:
I am surprised ulaw isn't permitted though, without this you won't be able to have end to end IP calls to other providers be it in NZ or in countries like the USA.

You have to remember ulaw is only a North American standard. More places in the world use alaw than ulaw. My understanding is that many American carriers have to interconnect with European providers using alaw so this may not be a big issue.

The whole IP interconnect issue is going to be a huge one in the next ~10 years as telco's all fight over things! The fight over peering were nothing!

Mighty Ape

Shop now at Mighty Ape (affiliate link).

bender

220 posts

Master Geek
+1 received by user: 17

#287173 5-Jan-2010 15:24

Sure, but for the sake of compatibility it wouldn't kill them to support alaw as first preference with fallback to ulaw... That way you avoid issues with hardware from American vendors (i.e. most of the PBX's) that prefers ulaw, as in the case of Cisco.

sbiddle

30853 posts

Uber Geek
+1 received by user: 9996

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#287176 5-Jan-2010 15:37

bender: Sure, but for the sake of compatibility it wouldn't kill them to support alaw as first preference with fallback to ulaw... That way you avoid issues with hardware from American vendors (i.e. most of the PBX's) that prefers ulaw, as in the case of Cisco.

I'm no Cisco guru but my understanding was that Cisco will happily speak alaw from external SIP trunks to an endpoint within the network. Some parts of the network internally can only handle ulaw but this doesn't affect calling in any way. Am I totally wrong here?

I don't want to go knocking Cisco but ulaw is only used in the USA and Japan. It's not a global standard. alaw is used everywhere else in the world and for a lot of international circuits. Maybe Cisco need to understand that! :-)

bender

220 posts

Master Geek
+1 received by user: 17

#287183 5-Jan-2010 15:59

Cisco works fine with many codecs (g722/g711/g729/others) on SIP, however Unity Express is ulaw only, so for example at the office where I am we run Unity Express and when you leave me a voicemail our CME box will change codecs with CallPlus to ulaw (which they support) in order to avoid transcoding.

If I were to set alaw only, voicemail will still work, however transcoding will be handled locally in CME, which takes up DSP resources. It's not that this can't be done, it's that DSP's are a) expensive and b) unnecessary when we're talking about interchangeable codecs like alaw/ulaw.

It's as much of an issue to transcode for voicemail since the calls are sporadic and short in length, but you have to keep in mind music on hold and auto attendants.

In our instance we have 2x DSP's installed, one of which is dedicated to conferencing, and one of which is dedicated to music on hold, voicemail and auto attendants. With g711/g722 enabled I can have 8 simultaneous transcoded calls in progress, with g729 enabled I can have just 2 simultaneous transcoded calls in progress.

If we had ulaw and alaw enabled on the SIP trunk then I could have as many calls as there are phones, since calls to voicemail/music on hold/auto attendants will switch to ulaw as necessary, and if Telecom so wish, back to alaw when voice resumes. If we only had alaw, then voice calls will be unlimited, but voicemail/auto attendant/music on hold in total becomes just 10 calls.

I seriously doubt whether Cisco would want to re-engineer Unity Express just for Telecom's deployment, given pretty much every other provider allows ulaw/alaw as a minimum. When they stick to one codec for these functions, it minimises CPU requirements as for example Unity Express doesn't need to have all its voice prompts recorded twice etc (since if it records in ulaw and alaw then the source files either have to be duplicated or transcode). Bear in mind Unity Express is an embedded virtual server on the router, we can't just throw hardware at it.

Obviously this only represents issues that Cisco users would face, but I imagine the problems are similar for Avaya/Nortel etc. Though Asterisk runs on much faster PC hardware, it still results in unnecessary duplication since you'd need to re-record all of the Asterisk voice prompts in alaw format to support native playback without transcoding.

CallPlus, WorldxChange and Orcon all support alaw and ulaw (if not more, I use g722 and g729 on CallPlus/WxC, unsure if Orcon permits) so surely Telecom can too?

savag3

188 posts

Master Geek
+1 received by user: 3

#287202 5-Jan-2010 17:11

sbiddle: I'm no Cisco guru but my understanding was that Cisco will happily speak alaw from external SIP trunks to an endpoint within the network. Some parts of the network internally can only handle ulaw but this doesn't affect calling in any way. Am I totally wrong here?

Yes. Cisco voip systems won't transcode alaw/ulaw without using hardware DSP's. Not all Cisco endpoints support alaw such as Unity and more importantly 7940 and 7960 phones. There are probably tens of thousands of these phones installed in Cisco voip systems throughout NZ. The Cisco recommended config for SIP trunks is to use a Cisco Unified Border Element between the SIP provider and the rest of the system. CUBE runs on IOS. You can add DSP's to a CUBE to do transcoding between alaw and ulaw. If you don't have sufficient DSP's and a ulaw only endpoint tries to use the alaw only SIP trunk the call will fail.

1 | 2