FOOD FOR THOUGHT Calling Cyprus from UK international

[papachumba]

We've been having problems calling cyprus, first the line would just cut out after a few seconds, now we are getting "all circuits busy"...
upon reporting it to our trunk provider they said they checked calling from our trunk and they do not get problems. I tried via 2 different providers, same problem (all circuits busy)
Could anyone offer any advice? (Asterisk Call Log below)

[2013-08-08 15:39:13] WARNING[10459]: translate.c:206 framein: no samples for g722tolin
    -- SIP/orbtalk-out-000000d7 is ringing
    -- SIP/orbtalk-out-000000d7 is making progress passing it to SIP/700-000000d6
    -- SIP/orbtalk-out-000000d7 is ringing
    -- SIP/orbtalk-out-000000d7 is making progress passing it to SIP/700-000000d6
    -- Got SIP response 503 "503-Service Unavailable" back from 193.104.103.6:5060
    -- SIP/orbtalk-out-000000d7 is circuit-busy
  == Everyone is busy/congested at this time (1:0/1/0)
    -- Executing [s@macro-dialout-trunk:23] NoOp("SIP/700-000000d6", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 34") in new stack
    -- Executing [s@macro-dialout-trunk:24] GotoIf("SIP/700-000000d6", "0?continue,1:s-CONGESTION,1") in new stack
    -- Goto (macro-dialout-trunk,s-CONGESTION,1)
    -- Executing [s-CONGESTION@macro-dialout-trunk:1] Set("SIP/700-000000d6", "RC=34") in new stack
    -- Executing [s-CONGESTION@macro-dialout-trunk:2] Goto("SIP/700-000000d6", "34,1") in new stack
    -- Goto (macro-dialout-trunk,34,1)
    -- Executing [34@macro-dialout-trunk:1] Goto("SIP/700-000000d6", "continue,1") in new stack
    -- Goto (macro-dialout-trunk,continue,1)
    -- Executing [continue@macro-dialout-trunk:1] NoOp("SIP/700-000000d6", "TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 34 - failing through to other trunks") in new stack
    -- Executing [continue@macro-dialout-trunk:2] Set("SIP/700-000000d6", "CALLERID(number)=700") in new stack
    -- Executing [0035726828282@from-internal:6] Macro("SIP/700-000000d6", "outisbusy,") in new stack
    -- Executing [s@macro-outisbusy:1] Progress("SIP/700-000000d6", "") in new stack
    -- Executing [s@macro-outisbusy:2] GotoIf("SIP/700-000000d6", "0?emergency,1") in new stack
    -- Executing [s@macro-outisbusy:3] GotoIf("SIP/700-000000d6", "0?intracompany,1") in new stack
    -- Executing [s@macro-outisbusy:4] Playback("SIP/700-000000d6", "all-circuits-busy-now&pls-try-call-later, noanswer") in new stack
    -- <SIP/700-000000d6> Playing 'all-circuits-busy-now.gsm' (language 'en')
    -- <SIP/700-000000d6> Playing 'pls-try-call-later.gsm' (language 'en')
    -- Executing [s@macro-outisbusy:5] Congestion("SIP/700-000000d6", "20") in new stack
  == Spawn extension (macro-outisbusy, s, 5) exited non-zero on 'SIP/700-000000d6' in macro 'outisbusy'
  == Spawn extension (from-internal, 0035726828282, 6) exited non-zero on 'SIP/700-000000d6'
    -- Executing [h@from-internal:1] Hangup("SIP/700-000000d6", "") in new stack
  == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/700-000000d6'

 

[atsak]

Got SIP response 503 "503-Service Unavailable" back from 193.104.103.6:5060
Are you trying to use g722 as the codec? Try with g711. This is your carrier saying it can't complete the call (for some reason).

 

[papachumba]

Yes, thats what I noticed... Weird thing is that other international calls work absolutely fine. Is it possible for a provider to be failing g722 for one destination and not the other? That stinks of infrastructure problems to me, and NAT traversal issues
I tried turning off g722 in SIP settings and leaving only ulaw,alaw&gsm on, no effect, same problem.

 

[papachumba]

Haha, here's a weird thing.
Our office tel system, a completely different provider, different setup, different phones, we tried calling this same number from that system - same problem.
This proves to me 100% that the problem lies somewhere between UK & Cyprus, and is affecting 1 or more networks used by VOIP providers in UK.
And it also tells me that possibly, all of these VOIP providers are using the same infrastructure to Cyprus (or at least one gateway which fails for all of them).
Providers are: Voipcheap, Siptel and Orbtalk.

 

[Hyksos]

So you have a lying provider...

upon reporting it to our trunk provider they said they checked calling from our trunk and they do not get problems

And you should open a ticket with all three for that.

 

[papachumba]

Funny how they are all lying about having their own infrastructure.
If this were the case, only 1 would have these problems, not all 3.

 

[Hyksos]

mmm no,
Having their own infra does not mean they can route call to the WORLD without using somebody else network.
No company do that on this earth... none.

It makes no sense, if the 5ESS at my telco has a problem, all the providers in the world will have the same problem calling me...

 

[papachumba]

Yes, but surely VOIP providers setup their own gateways within each country to lower their own costs, improve security and ensure quality?

 

[Hyksos]

no

 

[leemason]

No. Providers purchase minutes on the wholesale market for other International providers.

 

[leemason]

No. Providers purchase minutes on the wholesale market for other International providers.

 

[papachumba]

Well, its All obviously running through the same network, regardless of the provider is it not?
Im imagining an ageing router sitting somewhere between uk & cyprus failing voip calls for all providers lol. One of the providers whom i talked to, is convinced problem lies with us, heres why: they tested our trunk by connecting a softphone to it, and they claim the call goes through, proving that the trunk works and theyve been telling me problem is on our side.

 

[leemason]

They could we'll be correct in that case. Have you tried from your end just setting up a soft phone with the trunk details and trying to disl the number? It's worth a go.

 

[leemason]

They could we'll be correct in that case. Have you tried from your end just setting up a soft phone with the trunk details and trying to disl the number? It's worth a go.

 

[papachumba]

Thats my next step.
However still doesn't explain why our internal office phone system (different provider, different PBX, different network altogether) exhibits the same problem.

 

[papachumba]

Hah!
Considering they suggested using x-lite to confirm my trunk works, first thought I had in my head was "well x-lite is possibly using a different codec to the one im using on my PBX, so...
I turned OFF all codecs except GSM, connected the phone, dialed the number and lo and behold, the call goes through, stays connected and actually connects and rings within a second of me dialing it!
I presume they are battling with congestion to Cyprus, and are naturally stopping g722, ulaw & alaw, however gsm can go through... I guess their x-lite sofphone is using gsm by default and thats why it works without issues.

So, how comes this fails when my server is using g722,alaw,ulaw,gsm? I expected these PBXes and SIP protocol to automatically switch down to a lower codec if congestion occurs. Is this not possible? What to do? I do not want to leave only gsm running on my PBX, g722 is where its at!

 

[papachumba]

Even weirder, now all codecs work. Back to my initial setup, its all working as it should.
I give up

 

[leemason]

It's possible that your ITSP does not support G722. Many don't. They will always allow ulaw and alaw and the negotiation of codec is done between your PBX and the ITSP's trunking infrastructure. What happens further down the line should not affect/change the use of codecs so I doubt that a different codec will be used just because the call is to Cyprus.

 

[atsak]

It's possible that your ITSP does not support G722. Many don't. They will always allow ulaw and alaw and the negotiation of codec is done between your PBX and the ITSP's trunking infrastructure. What happens further down the line should not affect/change the use of codecs so I doubt that a different codec will be used just because the call is to Cyprus.

I am wondering if that's the case or not; for example a couple of my providers do not proxy RTP, and I'm thinking the RTP traffic has to conform to codec selection (but I do not, to be fair, understand the interplay between the networky RTP and the voicey codec part because I have never looked at it). If so, then it's theoretically possible you request your SIP trunk provider to honour a particular codec and they agree, but the upstream carrier never passes RTP because they can't support the codec request? I'm just thinking out loud - I have never done a deep dive into the codec negotiation game.

 

[TwigsUSAN]

If your provider allows one codec and the other provider uses a different codec, then your provider will transcode to the other providers codec.