[asterisk-users] Troubleshooting one-way voice... how to peek into SIP RTP?

Philip Prindeville philipp_subx at redfish-solutions.com
Mon Sep 29 03:33:14 CDT 2008


Philip Prindeville wrote:
> 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)
>   

Err, sorry.  Typo.  That was:

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


-Philip


> 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
>   




More information about the asterisk-users mailing list