[Help] One way sound - only on outgoing calls

Asterisk Asterisk Support
1

Hi,
I’m not sure quite how much information to put here - I don’t want to bore people with irrelevant details, but I don’t know what is relevant. I’m somewhat new to Asterisk, so please be gentle :smile:.

Problem: I have asterisk connecting to two SIP trunks. One works fine. The other works fine for incomming calls, but for outgoing calls I only get sound one way.

Setup: I have a Belkin F1PI241EGau ADSL router with NAT and an ATA. behind the NAT I have a linux box running debian Sarge. It has the standard Sarge asterisk package installed (1.0.7 + mods).

The Belkin ATA uses sip port 5060 (and seems to use RTP port 5002, but that isn’t configurable). Asterisk is set up to use SIP port 5061, and RTP ports 9500-9999. Ports 5061 and 9500-9999 forward from the NAT box to the linux box.

Asterisk has a simple setup. The ATA registers with it, and it registers with two SIP trunks, sipphone.com and iinetphone.iinet.net.au. The connection to sipphone.com works well. I can call in, I can call out, and I get sound both ways regardless of who called who.

The connection to iinetphone is a little more problematic. Inward calls get sound in both directions. Outgoing calls only get outgoing sound.

Interestingly, if I make the machine the DMZ machine, then calls start working in both directions. However this causes other wackiness with that machines net connection that I don’t understand, and I didn’t spend time working that out as I don’t want that machine outside the firewall anyway (it runs some insecure stuff for the internal network).

It sounds sort of like a port forwarding problem, but I have all ports that should be being used forwarded, don’t I? What am I missing?

I have logs of two short calls. They are very similar (some randomly generated ports differ, but they’re in range) up through where the first SIP packet

[color=blue]SIP/2.0 183 Session Progress[/color]

is sent from iinetphone to asterisk and asterisk sends a similar message to the ATA. After that, the successful log has:

[color=blue]Urgent handler
Dec 23 16:31:22 DEBUG[19311]: rtp.c:1193 ast_rtp_write: Ooh, format changed from unknown to ulaw

Sip read:
SIP/2.0 183 Session Progress
[packet from iinetphone]
[continues on to swap format, complain about incomplete RFC3389 support etc]
[/color]

where the unsuccessful log has:

[color=blue]Urgent handler
Dec 23 16:28:15 DEBUG[19311]: rtp.c:1193 ast_rtp_write: Ooh, format changed from unknown to ulaw
Dec 23 16:28:15 DEBUG[19311]: rtp.c:1193 ast_rtp_write: Ooh, format changed from unknown to ulaw
Dec 23 16:28:17 DEBUG[19311]: rtp.c:377 ast_rtcp_read: Got RTCP report of 112 bytes
Dec 23 16:28:18 DEBUG[19311]: rtp.c:377 ast_rtcp_read: Got RTCP report of 52 bytes
RFC3389: 1 bytes, level 4…
Dec 23 16:28:19 NOTICE[19311]: rtp.c:298 process_rfc3389: RFC3389 support incomplete. Turn off on client if possible
Dec 23 16:28:20 DEBUG[19311]: rtp.c:377 ast_rtcp_read: Got RTCP report of 112 bytes
[/color]

then the next SIP packet is from the ATA when I hang up.

I don’t understand why the missing SIP packet from iinetphone would be dropped that late in the stream. It should be coming on the same port as all the others. I don’t understand why the successful example has two Session Progress packets from iinetphone - the payloads look identical.

I don’t seem to be the only person with this problem:

forums.whirlpool.net.au/forum-re … 431207#r12

Any thoughts or suggestions on where to look next are most welcome.

Hope everyone has a wonderful festive season.

Will :-}

2

It isn’t clear from the above that the ATA is part of the router. It seems to sit outside the NAT part of the router. I’m assuming that there is enough port forwarding that the NAT is basically irrelevant.

The other piece of the data is that if I connect the ATA straight to iiNetPhone, then everything works fine. It isn’t just an iiNetPhone problem. :smile:

Be well,

Will :-}

3

You haven’t got nat=yes set in sip.conf, have you? It should be “no”. Although it probably wouldn’t work at all if you had.

4

Hmmm. I had nat=no in the general section, but then had it switched on in some of the individual sections lower down due to earlier fumbling. I switched it off everywhere but still have the same problem.

Thanks for the suggestion though.

Here is the relevant section from extensions.conf:

[BelkinA]

exten => s,1,Hangup
exten => i,1,Hangup ; invalid extension
; exten => t,1,Hangup ; timeout extension
exten => h,1,Hangup ; hangup

exten => _#.,1,SetCallerID(1XXXXXXXXXX)
exten => _#.,2,SetCIDName("Will Uther")
exten => _#.,3,Dial(SIP/${EXTEN:1}@sipphone_trunk)
exten => _#.,4,Hangup

exten => _.,1,SetCallerID(02XXXXXXXX) ; rumor has it that iiNet requires
                                      ; the correct caller ID - we'll give
                                      ; it regardless
exten => _.,2,SetCIDName("Will Uther")
exten => _.,3,Dial(SIP/${EXTEN}@iinet_trunk)
exten => _.,4,Hangup

[iinet-trunk]

exten => 02XXXXXXXX,1,Dial(SIP/BelkinA)
exten => 02XXXXXXXX,2,Hangup

and from sip.conf

[BelkinA]
type=friend
username=BelkinA
secret=NotPostingThisHere
host=dynamic
fromdomain=me.dyndns.org
port=5060
context=BelkinA

[iinet_trunk]
type=friend
;host=sip.nsw.iinet.net.au
host=203.55.231.193     ; iiNetPhone requires the IP address, not domain name
sendrpid=yes
username=02XXXXXXXX
fromuser=02XXXXXXXX
secret=NotPostingThisHere
fromdomain=iinetphone.iinet.net.au
context=iinet-trunk
canreinvite=no
insecure=very

I also tried nat=never, but that didn’t seem to help.

Will :-}

5

Well, it looks ok as far as i can tell. You may need to use ethereal or something similar to have a look at the packets themselves to work out what’s going on.

It certainly sounds like something to do with NAT - and possibly the way different equipment at the ITSP handles it. You need to find someone who’s using Asterisk with iiNet succesfully and find out what configuration they’re using. Have you tried asking on whirpool’s Asterisk forum?

6

I’ve definitely looked on whirlpool… but at that point I was looking for Belkin specific info. As it is a relatively new router there didn’t seem to be much there. Given that this now looks like an iiNet<->asterisk problem, I’ll give it another search.

Thanks again for the, simple but timely, advice :smile:

Be well,

Will :-}

P.S. Asterisk “sip debug” gives a good look at the SIP packets - I haven’t needed to pull out ethereal… yet. They look fine (but then much of the fun with SIP proxys is the way they seem to have different quirks). I don’t know enough about RTP to be looking at that too much just yet.

7

This may not be relevant to your problem, but I did have a similar one a while ago.

I had one-way audio on outbound calls, depite having the * box in the DMZ and triple checked all the config, I was still having the problem. Although when configured to use a different provider, it worked flawlessly.

It turned out that the provider I was using did something slightly differently from most other VoIP providers, to this day I do not know what. However, the router I was using (a netgear) didnt seem to properly pass all the rtp data through to the * box hence causing the one-way audio.

I changed the router, put my * box in the DMZ and with no further config everything worked perfectly!