asterisk users - Sep 2008 - Troubleshooting one-way voice... how to peek into SIP RTP?

I've got the following situation.  I'm running Asterisk 1.4.18 on a 
firewall/gateway machine, with some SPA-942 (f/w 5.1.15(a)) phones 
behind it.

I'm peering SIP with a Coppercom switch sitting behind an SBC.

On outbound calls, I get 2-way voice, no worries.

On inbound calls, I get one-way voice (I can hear the caller but they 
can't hear me).

I've looked at tcpdumps of the RTP traffic, and the addresses and port 
numbers correspond to what's in the SIP INVITE/OK messages (assuming 
that they don't somehow get munged by NAT after tcpdump looks at them -- 
there is no NAT device upstream of my Asterisk firewall).

I'll look into using Record() or Monitor() to capture the phone call, 
but if there's any conversion being done by codecs then that won't 
eliminate the possibility that the code itself is misconfigured or buggy 
and generating a bad stream on one of the legs...

Anyone have an idea about how to best go about troubleshooting this?

Thanks,

-Philip

A similar issue happens to us.
Make sure that, for inbound AND outbound calls rtp packets are reaching the 
other endpoint.
If a NAT device(s) is between the endpoints make sure that the device NATs the 
traffic on BOTH ways (inbound AND outbound).

Regards

On Saturday 27 September 2008 23:54:37 Philip Prindeville
wrote:
> I've got the following situation.  I'm running Asterisk 1.4.18 on a
> firewall/gateway machine, with some SPA-942 (f/w 5.1.15(a)) phones
> behind it.
>
> I'm peering SIP with a Coppercom switch sitting behind an SBC.
>
> On outbound calls, I get 2-way voice, no worries.
>
> On inbound calls, I get one-way voice (I can hear the caller but they
> can't hear me).
>
> I've looked at tcpdumps of the RTP traffic, and the addresses and port
> numbers correspond to what's in the SIP INVITE/OK messages (assuming
> that they don't somehow get munged by NAT after tcpdump looks at them
--
> there is no NAT device upstream of my Asterisk firewall).
>
> I'll look into using Record() or Monitor() to capture the phone call,
> but if there's any conversion being done by codecs then that won't
> eliminate the possibility that the code itself is misconfigured or buggy
> and generating a bad stream on one of the legs...
>
> Anyone have an idea about how to best go about troubleshooting this?
>
> Thanks,
>
> -Philip
>
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> AstriCon 2008 - September 22 - 25 Phoenix, Arizona
> Register Now: http://www.astricon.net
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users

On Sat, Sep 27, 2008 at 5:54 PM, Philip Prindeville
<philipp_subx at redfish-solutions.com> wrote:
> I've got the following situation.  I'm running Asterisk 1.4.18 on a
> firewall/gateway machine, with some SPA-942 (f/w 5.1.15(a)) phones
> behind it.
>
> I'm peering SIP with a Coppercom switch sitting behind an SBC.
>
> On outbound calls, I get 2-way voice, no worries.
>
> On inbound calls, I get one-way voice (I can hear the caller but they
> can't hear me).
>
> I've looked at tcpdumps of the RTP traffic, and the addresses and port
> numbers correspond to what's in the SIP INVITE/OK messages (assuming
> that they don't somehow get munged by NAT after tcpdump looks at them
--
> there is no NAT device upstream of my Asterisk firewall).
>
> I'll look into using Record() or Monitor() to capture the phone call,
> but if there's any conversion being done by codecs then that won't
> eliminate the possibility that the code itself is misconfigured or buggy
> and generating a bad stream on one of the legs...
>
> Anyone have an idea about how to best go about troubleshooting this?
>
> Thanks,
>
> -Philip
>
Philip,

  We were recently having a few call quality problems with one of our
carriers, including very mysterious one way audio on specific pieces
of equipment.

  I created a call generator using Playtones/Monitor to record all
four audio paths (only two are important) of a successful call and
analyze the resulting recordings with ecasound to detect distortion,
one-way audio, audio drops, etc.  After several hundred calls we were
able to get the carrier to correct the offending pieces of equipment.

  I'm looking into a way to do this in real time but for now this
collection of scripts works pretty well.  It's not ready for release
but I could get it to you shortly for some testing.

-- 
Kristian Kielhofner
http://blog.krisk.org

Well, things just got a lot more interesting...  Adding Monitor() to an 
extension ends the one-way voice problem on inbound calls!

So an incoming call gets handled as:

[ctc-incoming]
exten => 208345****,1,Noop()
exten => 208345****,n,Log(NOTICE: RDNIS: ${CALLERID(rdnis)} ANI: 
${CALLERID(ani)})
exten => 208345****,n,Goto(redfish-pstn,s,1)
...

[redfish-pstn]
exten => s,1(incoming),Noop()
exten => s,n,Answer()
exten => s,n,Wait(0.5)
...
some filters for bogus ANI's like 888888888.... goes to badani below

exten => s,n(exten),Background(vm-enter-num-to-call)
exten => s,nWaitExten(5)
exten => s,n(goodbye),Playback(vm-goodbye)
exten => s,n(end),Hangup()

exten => s,n(badani),Log(DEBUG,ANI: ${CALLERID(ani)} clearing)
exten => s,n,Playback(privacy-unident)
exten => s,n,Wait(0.5)
exten => s,n,Congestion()
exten => s,n,Hangup()

include => redfish-extens

exten => i,1,NoOp(Invalid: ${EXTEN})
exten => i,n,Playback(pbx-invalid)
exten => i,n,Goto(s,exten)

exten => t,1,Goto(s,goodbye)

[redfish-extens]
...

exten => 113,1,Monitor(wav,,w)            ; for debugging
exten => 113,n,Macro(stdexten,113,${GUEST},redfish)
exten => 113,n,Goto(s,exten)

...

exten => 113,1,Macro(stdexten,119,${GUEST},redfish)
exten => 113,n,Goto(s,exten)

So I don't get this at all.  If I dial 208345****, then enter '119'
as
the extension, it rings on a few phones (including a Xlite softphone) 
and if I pick up on any of those, I get one-way voice (I can hear the 
caller but they can't hear me).

If I enter '113' as the extension, it rings on two SPA-942's (one of
which is the same as above, just a different line presentation)... and 
if I answer, then I get two-way voice!  Only difference is the Monitor() 
statement.

I'm starting to suspect it's a CODEC issue in Asterisk, though (a) why 
Asterisk would need to transcode a call between two uLaw endpoints, I 
don't know... and (b) why is it staying in the Media path at all?

I have the SIP peer that the calls come in on as:

[sip-proxy]
...
type=peer
nat=no
canreinvite=no
reinvite=no

Anyone know why the Monitor() would change the duplex(ity) of the audio 
stream?  I'm baffled (no pun intended).  And is there any debugging I 
can turn on to reveal CODEC behavior that might differ from 113 and 119?

Thanks,

-Philip



Philip Prindeville wrote:
> I've got the following situation.  I'm running Asterisk 1.4.18 on a
> firewall/gateway machine, with some SPA-942 (f/w 5.1.15(a)) phones 
> behind it.
>
> I'm peering SIP with a Coppercom switch sitting behind an SBC.
>
> On outbound calls, I get 2-way voice, no worries.
>
> On inbound calls, I get one-way voice (I can hear the caller but they 
> can't hear me).
>
> I've looked at tcpdumps of the RTP traffic, and the addresses and port 
> numbers correspond to what's in the SIP INVITE/OK messages (assuming 
> that they don't somehow get munged by NAT after tcpdump looks at them
--
> there is no NAT device upstream of my Asterisk firewall).
>
> I'll look into using Record() or Monitor() to capture the phone call, 
> but if there's any conversion being done by codecs then that won't 
> eliminate the possibility that the code itself is misconfigured or buggy 
> and generating a bad stream on one of the legs...
>
> Anyone have an idea about how to best go about troubleshooting this?
>
> Thanks,
>
> -Philip
>