dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
914

Adam4
Premium Member
join:2011-05-30
Woodland Hills, CA

Adam4

Premium Member

Small problem with UKDDI that I have worked around

I have a minor problem with DIDs from UKDDI that I have successfully worked around, but it would be interesting to me, and perhaps informative to the forum, if we could get to the bottom of the actual problem.

I have three free UK DIDs from UKDDI. When I point them to a SIP URI that points directly to my Asterisk system, I get one way audio. I can hear the caller, but the caller cannot hear me. These worked properly when I originally set this up, but some time last year, this problem started.

However, I have DIDs from other providers pointed to the very same SIP URI in exactly the same way, and they work perfectly OK, two free NY DIDs and an iNum from Callcentric, and a free DID from IPComms.

The SIP URI is to a domain name that I host in my own professionally hosted DNS with an A record pointing to my Time Warner cable service. The Asterisk box is connected to the cable modem via an Apple Airport router.

My workaround is that the UKDDI DIDs are currently pointed to a virtual DID at VoIP.ms on my account that is registered to my Asterisk box and serves as my primary incoming service. Configured in this way, the UKDDI DIDs work just fine.

But the VoIP.ms virtual DID costs .25 a month plus .0001 per minute, I know, $3 a year, far from bank-breaking. But my workaround involves pointing all three UKDDI DIDs to the same VoIP.ms virtual DID, giving up the ability to distinguish between them on incoming calls. I could get three VoIP.ms virtual DIDs, but then, to my mind, $9 a year sort of ruins the idea of "free" DIDs from UKDDI.

So, anyone have any idea why DIDs to SIP URIs on my Asterisk system from Callcentric and IPComms work, but using the same SIP URI with DIDs from UKDDI doesn't work?
Stewart
join:2005-07-13

Stewart

Member

I assume that you have the RTP port range forwarded in the Airport to Asterisk and that the relevant settings for the UKDDI trunks are the same as those for Callcentric / IPComms. If not, please explain.

Run tcpdump on the Asterisk machine and capture a failing call. Copy the file to a PC or Mac and open it in Wireshark. Can you see anything obvious wrong with the outbound RTP? Normally, it should go to the same IP address and port at UKDDI as the incoming RTP is coming from, and it should be using the same codec and packetization.

If you see no trouble, the Airport might be translating the RTP source port, which could cause UKDDI to ignore the packets. Can you rig a way to capture traffic between Airport and modem? If so, you should be able so see a difference between the working and failing cases.
Stewart

Stewart to Adam4

Member

to Adam4
A possible free workaround may be to point the UKDDI DIDs to 1777xxxxxxx@in.callcentric.com. If it works to include an extension number yyy (1777xxxxxxxyyy@in.callcentric.com), you could distinguish the DIDs that way. Or, use call treatments to send them to different URIs on your Asterisk.

Adam4
Premium Member
join:2011-05-30
Woodland Hills, CA

Adam4

Premium Member

Well... OK... It gets even stranger. Preparatory to testing, I had to switch one of my UKDDIs back to a direct SIP URI to my Asterisk box. After doing this, it worked with normal two-way audio. BUT! Only for about 4 test calls. Then it went back to one-way audio again, no changes on my end between the calls that succeeded and the one that failed.

I'm not an expert with Wireshark, as far as I can see, the UKDDI packets are coming in and going out on corresponding ports which are open and within the range that is forwarded to my Asterisk box in my router.

I don't see anywhere in Wireshark where you can tell what the codec is. It shows packet length 180 which is the same as the outgoing call to make the test. What else should I be looking at?

Thanks for your help on this.
Adam4

Adam4

Premium Member

Update. I was truncating the tcpdump. I'm capturing it correctly now, I see the codec and lots of other info.

I now have a capture file containing two calls, one that was OK, and the following one that failed. I can't see any difference between the two calls in Wireshark. Both use incoming ports within my RTP range. Both use G.711 PCMU. I'm at a loss...

arpawocky
Premium Member
join:2014-04-13
Columbus, OH

arpawocky

Premium Member

said by Adam4:

Both use incoming ports within my RTP range.

You said you can hear the caller, but not vice versa - so its not the incoming RTP, but rather the outgoing RTP, that is somehow problematic.

Did you capture the RTP packets too, or just the SIP?

Anything odd about the SDP provided by UKDDI?

Adam4
Premium Member
join:2011-05-30
Woodland Hills, CA

Adam4

Premium Member

Yes, it looks like all the RTP packets were recorded in the file.

But I don't know enough about SIP and Wireshark so I'm not sure about the answers to those questions. Someone is taking a second look at my tcpdump for me...
Stewart
join:2005-07-13

Stewart to Adam4

Member

to Adam4
Just a guess here. I had a very similar problem with an unrelated provider (TrueNet Talk). As in your case, their initial INVITE specified alaw as the preferred codec but also listed ulaw. However, if ulaw was sent, they would discard the audio.

Your case is more complex because it sometimes works. A further guess is that UKDDI has one or more servers with the issue, and one or more without. In the capture file, the working and failing calls came from different servers (87.117.74.1 and 87.117.75.1 respectively).

Try forcing alaw (disallow=all followed by allow=alaw) for the UKDDI trunks. If it doesn't fix the problem, confirm that Asterisk is really sending alaw to UKDDI. Also, note whether there is a relationship between which server sends the call and whether it fails.

I noticed something else that's very strange. When you answer the failing call, the audio being sent by CircleNet doesn't just go silent, it stops flowing! This may merely indicate that the call was handled entirely by IP and TDM was never involved. Or, it may give a clue as to what is going wrong.

Adam4
Premium Member
join:2011-05-30
Woodland Hills, CA

Adam4

Premium Member

said by Stewart:

A further guess is that UKDDI has one or more servers with the issue, and one or more without. In the capture file, the working and failing calls came from different servers (87.117.74.1 and 87.117.75.1 respectively).

This must have been a coincidence. I just saw a call from 87.117.74.1 that failed.

Try forcing alaw (disallow=all followed by allow=alaw) for the UKDDI trunks.

Since SIP URI calls come in the default context, I added this to the [general] context of sip.conf:

disallow=all
allow=alaw

Calls still failed.

confirm that Asterisk is really sending alaw to UKDDI.

Unfortunately, I don't know how to do this. I think I've taken this as far as I can.

I noticed something else that's very strange. When you answer the failing call, the audio being sent by CircleNet doesn't just go silent, it stops flowing!

I have noticed outgoing CircleNet calls do appear to progress differently from calls of other providers on my system. However, the one-way audio problem on incoming UKDDI calls happens no matter what provider I use for the outgoing leg of the test call.
Stewart
join:2005-07-13

Stewart

Member

If you are correctly forcing alaw, the RTP packets to and from the UKDDI server will show in Wireshark's summary line as PT=ITU-T G.711 PCMA (the old capture showed PCMU).

Assuming that it's not a codec issue, my next guess is that the Airport might be sometimes translating the source port number and UKDDI may be fussy about that. Of course, with port forwarding in place that shouldn't happen. (I assume that the Airport has a public IP on its WAN interface, i.e. the modem is in bridge mode. If not, please explain.)

Ways to check this include: Use a dumb hub, managed switch, or PC with two NICs to capture traffic between router and modem. Temporarily substitute a different router (you may have an old one, perhaps non Wi-Fi). Temporarily connect your Asterisk directly to the modem.

If it's not this sort of low level networking issue, either, I'm pretty much out of ideas. Though it's conceivable that TWC is blocking packets based on destination port, IMO they would have no reason to do that and it's very unlikely. I looked at the RTP sent to UKDDI and can see nothing wrong. Even listened to you blowing into the mic and it sounded fine.

I know nothing about UKDDI as a company. Might it be possible to get them to do a trace at their end? That would tell us if your RTP was received corrupted, from the wrong port, or not at all.

arpawocky
Premium Member
join:2014-04-13
Columbus, OH

arpawocky to Stewart

Premium Member

to Stewart
said by Stewart:

I noticed something else that's very strange. When you answer the failing call, the audio being sent by CircleNet doesn't just go silent, it stops flowing! This may merely indicate that the call was handled entirely by IP and TDM was never involved. Or, it may give a clue as to what is going wrong.

I would think the fact that the audo was sent by CircleNet at all would indicate that the call was handled entirely by IP, no? (and that the CircleNet is the caller's provider, and that Circlenet and UKDDI (or their respective underlying providers) peer directly via SIP) Or am I missing something here?
Stewart
join:2005-07-13

Stewart

Member

AFAIK CircleNet always proxies the media, so (unless there are clues in the RTP headers) you can't tell where they are getting it from. Also, Adam's calls on CircleNet to his UKDDI number (and perhaps all calls) get an immediate 200 OK, so you see the call progress audio coming from CircleNet. This is FAS, though probably not in the billing sense. When the failing call was answered, CircleNet stopped sending RTP. When the good call was answered, the RTP stream continued normally, with the ringback tone replaced by speech, as expected.

Anyhow, just for laughs, I signed up for UKDDI to try to reproduce the problem. Unfortunately, they had no London numbers available so I chose Manchester. Ten test calls were made. Although all calls had two-way audio, there was a bit of trouble. Two of the calls did not deliver my (Reno, US) CLI. I suspect that CircleNet used a different carrier for those calls, but the trouble could have been elsewhere. And, on those two calls, audio from callee to caller did not pass until about one second after answer. If this happened to Adam and his tests were very brief, he might have mistaken it for one-way audio. Also, I saw no FAS, but don't know if there is something different about our CircleNet setups, whether London vs. Manchester matters, or whether Adam's California CLI, accidentally formatted without the leading 1 so it looks like Japan, might have made a difference.

arpawocky
Premium Member
join:2014-04-13
Columbus, OH

arpawocky

Premium Member

said by Stewart:

AFAIK CircleNet always proxies the media, so (unless there are clues in the RTP headers) you can't tell where they are getting it from. Also, Adam's calls on CircleNet to his UKDDI number (and perhaps all calls) get an immediate 200 OK, so you see the call progress audio coming from CircleNet. This is FAS, though probably not in the billing sense. When the failing call was answered, CircleNet stopped sending RTP. When the good call was answered, the RTP stream continued normally, with the ringback tone replaced by speech, as expected.

Ok, makes more sense now. For some reason I thought that you meant that the media was coming from CircleNet on the UKDDI leg of the call.

Regarding FAS: Could even be something in Adam's dialplan. I've seen things like:
exten => _X.,1,Answer()
  same => n,Dial(SIP/foo/${EXTEN})
  same => n,Voicemail(${EXTEN})
 
way too many times... Sadly, some tutorials actually recommend answering first "so you dont forget" and then executing all other dialplan logic afterwards!! : /

What stumps me about this is that:

a) not only is it intermittent, but that the problem doesnt happen at all when Adam first sends the call to another SIP URI that then sends it on to his asterisk's SIP URI.

and

b) it is the reverse of the typical one-way-audio situation.