Help getting gtalk channel running

Howdy,

Asterisk 1.8 controls this with an option in the SIP channel configuration called “directmedia.”

Here’s the breakdown on it:

;----------------------------------- MEDIA HANDLING --------------------------------
; By default, Asterisk tries to re-invite media streams to an optimal path. If there's
; no reason for Asterisk to stay in the media path, the media will be redirected.
; This does not really work well in the case where Asterisk is outside and the
; clients are on the inside of a NAT. In that case, you want to set directmedia=nonat.
;
;directmedia=yes       ; Asterisk by default tries to redirect the
                                ; RTP media stream to go directly from
                                ; the caller to the callee.  Some devices do not
                                ; support this (especially if one of them is behind a NAT).
                                ; The default setting is YES. If you have all clients
                                ; behind a NAT, or for some other reason want Asterisk to
                                ; stay in the audio path, you may want to turn this off.

                                ; This setting also affect direct RTP
                                ; at call setup (a new feature in 1.4 - setting up the
                                ; call directly between the endpoints instead of sending
                                ; a re-INVITE).

                                ; Additionally this option does not disable all reINVITE operations.
                                ; It only controls Asterisk generating reINVITEs for the specific
                                ; purpose of setting up a direct media path. If a reINVITE is
                                ; needed to switch a media stream to inactive (when placed on
                                ; hold) or to T.38, it will still be done, regardless of this 
                                ; setting. Note that direct T.38 is not supported.

;directmedia=nonat              ; An additional option is to allow media path redirection
                                ; (reinvite) but only when the peer where the media is being
                                ; sent is known to not be behind a NAT (as the RTP core can
                                ; determine it based on the apparent IP address the media
                                ; arrives from).

;directmedia=update             ; Yet a third option... use UPDATE for media path redirection,
                                ; instead of INVITE. This can be combined with 'nonat', as
                                ; 'directmedia=update,nonat'. It implies 'yes'.

So, for phones behind NAT, or if NAT’s giving you trouble with media, it’s a good idea to try directmedia=no.

Cheers.

[quote=“malcolmd”]Howdy,

Asterisk 1.8 controls this with an option in the SIP channel configuration called “directmedia.”

Here’s the breakdown on it:

;----------------------------------- MEDIA HANDLING --------------------------------
; By default, Asterisk tries to re-invite media streams to an optimal path. If there's
; no reason for Asterisk to stay in the media path, the media will be redirected.
; This does not really work well in the case where Asterisk is outside and the
; clients are on the inside of a NAT. In that case, you want to set directmedia=nonat.
;
;directmedia=yes       ; Asterisk by default tries to redirect the
                                ; RTP media stream to go directly from
                                ; the caller to the callee.  Some devices do not
                                ; support this (especially if one of them is behind a NAT).
                                ; The default setting is YES. If you have all clients
                                ; behind a NAT, or for some other reason want Asterisk to
                                ; stay in the audio path, you may want to turn this off.

                                ; This setting also affect direct RTP
                                ; at call setup (a new feature in 1.4 - setting up the
                                ; call directly between the endpoints instead of sending
                                ; a re-INVITE).

                                ; Additionally this option does not disable all reINVITE operations.
                                ; It only controls Asterisk generating reINVITEs for the specific
                                ; purpose of setting up a direct media path. If a reINVITE is
                                ; needed to switch a media stream to inactive (when placed on
                                ; hold) or to T.38, it will still be done, regardless of this 
                                ; setting. Note that direct T.38 is not supported.

;directmedia=nonat              ; An additional option is to allow media path redirection
                                ; (reinvite) but only when the peer where the media is being
                                ; sent is known to not be behind a NAT (as the RTP core can
                                ; determine it based on the apparent IP address the media
                                ; arrives from).

;directmedia=update             ; Yet a third option... use UPDATE for media path redirection,
                                ; instead of INVITE. This can be combined with 'nonat', as
                                ; 'directmedia=update,nonat'. It implies 'yes'.

So, for phones behind NAT, or if NAT’s giving you trouble with media, it’s a good idea to try directmedia=no.

Cheers.[/quote]

Ok. Makes sense. I’ll mess around with it and see what happens (after backing up my working config of course).

I don’t want to overdo my questions, and if you’re sick of dealing with me I totally get it. You’ve been way more than helpful, but I know how annoying it can be to have people constantly come back for more. Getting questions answered on forums so quickly and brilliantly is addictive like crack. So I’m going to throw this question out there, and if you’ve had enough, I totally get it; I can research and start more threads if need be.

That being said; I’d like to get this sucker running as a daemon at startup. So far I’ve been manually starting it using sudo asterisk -cvvvvv. I see there’s already a file /etc/init.d/asterisk. I try starting it that way and this happens:

jp@gob:~$ sudo /etc/init.d/asterisk start [sudo] password for jp: /etc/init.d/asterisk: line 57: syntax error near unexpected token `&' jp@gob:~$

I haven’t touched this file since the install. I really know nothing about how scripts in /etc/init.d are written. It looks like there’s something funky with the “Usage:” echo (that’s near line 57), but am helpless to know what…

[code]jp@gob:~$ cat /etc/init.d/asterisk
#!/bin/bash

BEGIN INIT INFO

Provides: asterisk

Required-Start: $network $syslog

Required-Stop: $network $syslog

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-Description: Asterisk daemon.

Description: This script handles start/stop states of asterisk.

END INIT INFO

set -e
set -a
PATH=/usr/local/sbin/:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="Asterisk"
NAME=amportal
DAEMON=/usr/sbin/$NAME

test -x $DAEMON || exit 0

d_start() {
amportal start
}

d_stop() {
amportal stop
}

d_reload() {
amportal restart
}

case “$1” in

start)
echo -n "Starting $DESC: $NAME"
d_start
echo “.”
;;

stop)
echo -n "Stopping $DESC: $NAME"
d_stop
echo “.”
;;

restart|force-reload)
echo -n "Restarting $DESC: $NAME"
d_stop
sleep 10
d_start
echo “.”
;;

*)

echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" > &2
exit 3

;;

esac

exit 0
jp@gob:~$[/code]

It looks like if I can get asterisk to start with this, I can just run update-rc.d asterisk defaults to get it to run at boot.

Got it!

Used the script from /usr/src/asterisk/contrib/init.d/rc.debian.asterisk

Took a minute to realize you actually have to change ASTERISK_SBIN_DIR to the actual dir…duh.

Time to tweak for call quality!

For basic call quality, you should already be set - the Google calls are going to move around using G.711 ulaw, and that should be the default codec for SipDroid also. :smile:

Shoot. I jumped the gun. I can make calls out from SIPDroid. But when calling my GV number from my work phone this happens:

I hear it ring once in the receiver of my work phone (SIPDroid never rings). I hear silence for maybe 20 seconds. I get a hangup sound on my work phone. On my SIPDroid it displays the ‘call ended’ screen.

Trying to read through the SIP debug. This stands out to me:

--- (7 headers 0 lines) --- -- Nobody picked up in 20000 ms Scheduling destruction of SIP dialog '3e8a0f2614e3566b0f583609056a7f49@96.252.xxx.xxx:5060' in 32000 ms (Method: INVITE) Reliably Transmitting (NAT) to 174.252.xxx.xxx:61346: CANCEL sip:JP_Android@174.252.xxx.xxx:61346;transport=udp SIP/2.0 Via: SIP/2.0/UDP 96.252.xxx.xxx:5060;branch=z9hG4aK6c0385d1;rport Max-Forwards: 70 From: "+1XXXXXX5477@voice.google.com/srvres-MTAuMTnuOTkuFzE60Tg0MA==" <sip:asterisk@96.252.xxx.xxx>;tag=as490394e5 To: <sip:JP_Android@174.252.xxx.xxx:61346;transport=udp> Call-ID: 3e8a0f2613f3566f0f673709056a7f49@96.252.xxx.xxx:5060 CSeq: 102 CANCEL User-Agent: Asterisk PBX SVN-trunk-r298201 Content-Length: 0

That CANCEL sip: looks odd. Not sure what’s going on there.

What’s before the CANCEL? The CANCEL is what’s happening after things have already gone sad.

Here’s the last call I tried. Too much to remove IP addresses. Oh well.

This time it rang and rang (SIPDroid never rang) until GV voicemail picked up. SIPDroid showed the ‘call ended’ screen.

[code] – Executing [jp.briggs@gmail.com@gv-inbound:1] Answer(“Gtalk/+15082335477-0d7c”, “”) in new stack
[Dec 16 14:59:37] WARNING[31636]: res_jabber.c:2753 aji_recv_loop: JABBER: socket read error
– Executing [jp.briggs@gmail.com@gv-inbound:2] Wait(“Gtalk/+15082335477-0d7c”, “1”) in new stack
– Executing [jp.briggs@gmail.com@gv-inbound:3] SendDTMF(“Gtalk/+15082335477-0d7c”, “1”) in new stack
– Executing [jp.briggs@gmail.com@gv-inbound:4] Dial(“Gtalk/+15082335477-0d7c”, “SIP/JP_Android”) in new stack
== Using SIP RTP CoS mark 5
Audio is at 5060
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x8 (alaw) to SDP
Adding codec 0x800000000000 (testlaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 174.252.35.9:61373:
INVITE sip:JP_Android@174.252.35.9:61373;transport=udp SIP/2.0
Via: SIP/2.0/UDP 96.252.123.128:5060;branch=z9hG4bK2ce10d1c;rport
Max-Forwards: 70
From: "+15082335477@voice.google.com/srvres-MTAuMjI5LjY3LjE0OTo5ODYw" sip:asterisk@96.252.123.128;tag=as1feb3a68
To: sip:JP_Android@174.252.35.9:61373;transport=udp
Contact: sip:asterisk@96.252.123.128:5060
Call-ID: 184731330d902d997d8b461704fdd046@96.252.123.128:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX SVN-trunk-r298201
Date: Thu, 16 Dec 2010 19:59:38 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 324

v=0
o=root 1826175664 1826175664 IN IP4 96.252.123.128
s=Asterisk PBX SVN-trunk-r298201
c=IN IP4 96.252.123.128
t=0 0
m=audio 14590 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv


-- Called JP_Android

<— SIP read from UDP:174.252.35.9:61373 —>
SIP/2.0 100 Trying
Call-ID: 184731330d902d997d8b461704fdd046@96.252.123.128:5060
CSeq: 102 INVITE
From: "+15082335477@voice.google.com/srvres-MTAuMjI5LjY3LjE0OTo5ODYw" sip:asterisk@96.252.123.128;tag=as1feb3a68
To: sip:JP_Android@174.252.35.9:61373;transport=udp
Via: SIP/2.0/UDP 96.252.123.128:5060;received=96.252.123.128;rport=5060;branch=z9hG4bK2ce10d1c
Content-Length: 0

<------------->
— (7 headers 0 lines) —
Scheduling destruction of SIP dialog ‘184731330d902d997d8b461704fdd046@96.252.123.128:5060’ in 32000 ms (Method: INVITE)
Reliably Transmitting (NAT) to 174.252.35.9:61373:
CANCEL sip:JP_Android@174.252.35.9:61373;transport=udp SIP/2.0
Via: SIP/2.0/UDP 96.252.123.128:5060;branch=z9hG4bK2ce10d1c;rport
Max-Forwards: 70
From: "+15082335477@voice.google.com/srvres-MTAuMjI5LjY3LjE0OTo5ODYw" sip:asterisk@96.252.123.128;tag=as1feb3a68
To: sip:JP_Android@174.252.35.9:61373;transport=udp
Call-ID: 184731330d902d997d8b461704fdd046@96.252.123.128:5060
CSeq: 102 CANCEL
User-Agent: Asterisk PBX SVN-trunk-r298201
Content-Length: 0


Scheduling destruction of SIP dialog ‘184731330d902d997d8b461704fdd046@96.252.123.128:5060’ in 32000 ms (Method: INVITE)
== Spawn extension (gv-inbound, jp.briggs@gmail.com, 4) exited non-zero on ‘Gtalk/+15082335477-0d7c’

<— SIP read from UDP:174.252.35.9:61373 —>
SIP/2.0 200 OK
Call-ID: 184731330d902d997d8b461704fdd046@96.252.123.128:5060
CSeq: 102 CANCEL
From: "+15082335477@voice.google.com/srvres-MTAuMjI5LjY3LjE0OTo5ODYw" sip:asterisk@96.252.123.128;tag=as1feb3a68
To: sip:JP_Android@174.252.35.9:61373;transport=udp;tag=s138+1+1420001+15f80cf3
Via: SIP/2.0/UDP 96.252.123.128:5060;received=96.252.123.128;rport=5060;branch=z9hG4bK2ce10d1c
Content-Length: 0

<------------->
— (7 headers 0 lines) —

<— SIP read from UDP:174.252.35.9:61373 —>
SIP/2.0 487 Request Terminated
Call-ID: 184731330d902d997d8b461704fdd046@96.252.123.128:5060
CSeq: 102 INVITE
From: "+15082335477@voice.google.com/srvres-MTAuMjI5LjY3LjE0OTo5ODYw" sip:asterisk@96.252.123.128;tag=as1feb3a68
To: sip:JP_Android@174.252.35.9:61373;transport=udp;tag=s138+1+1420001+15f80cf3
Via: SIP/2.0/UDP 96.252.123.128:5060;received=96.252.123.128;rport=5060;branch=z9hG4bK2ce10d1c
Server: Sipdroid/2.0.1 beta/Droid
Content-Length: 0

<------------->
— (8 headers 0 lines) —
Transmitting (NAT) to 174.252.35.9:61373:
ACK sip:JP_Android@174.252.35.9:61373;transport=udp SIP/2.0
Via: SIP/2.0/UDP 96.252.123.128:5060;branch=z9hG4bK2ce10d1c;rport
Max-Forwards: 70
From: "+15082335477@voice.google.com/srvres-MTAuMjI5LjY3LjE0OTo5ODYw" sip:asterisk@96.252.123.128;tag=as1feb3a68
To: sip:JP_Android@174.252.35.9:61373;transport=udp;tag=s138+1+1420001+15f80cf3
Contact: sip:asterisk@96.252.123.128:5060
Call-ID: 184731330d902d997d8b461704fdd046@96.252.123.128:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX SVN-trunk-r298201
Content-Length: 0


Really destroying SIP dialog ‘184731330d902d997d8b461704fdd046@96.252.123.128:5060’ Method: INVITE
gob*CLI>[/code]

For your SIPDroid peer, do you have directmedia set to no?

I just added it to the declaration of the [JP_Android] section of sip.conf. Restarted Asterisk. Same outcome. This is probably a weird setup too. When I’m out of the house, my SIPDroid will be non-NAT’d on the VZW network. When I’m home, it’ll be on WiFi on the same LAN as the Asterisk server.

Grrrr

Directmedia shouldn’t cause a problem there.

Can you place other calls from that Asterisk server to your SIPDroid device? Calls that don’t come from Google? A call that originates from Asterisk, for example?

[quote=“malcolmd”]Directmedia shouldn’t cause a problem there.

Can you place other calls from that Asterisk server to your SIPDroid device? Calls that don’t come from Google? A call that originates from Asterisk, for example?[/quote]

Time for me to once again prove my utter lack of experience. Can I place a test call from the Asterisk CLI? And you mean don’t call my GV number, but rather call my extension itself? I don’t have any other SIP devices currently configured, but can maybe set one up on a PC somewhere.

I will also try to place a call to my GV number while at home on my LAN.

Setting up a PC on the same LAN w/ a softclient would be simplest. Windows: Try X-Lite. Mac, try X-Lite or Blink.

Not blowing this off. Just taking a while to figure out how to incorporate a new extension in my dialplan. I really suck at this!

No worries.

First, build your SIP peer for the additional device.
Example at:
wiki.asterisk.org/wiki/display/ … ing+Google

In your dialplan then, just build an extra extension in the same context. In fact, if you don’t already have an extension for your SIPDroid device, just build one for that - we’re just testing here.

e.g.

exten => 100,1,Answer()
exten => 100,n,Dial(SIP/firstpeer,20)

exten => 101,1,Answer()
exten => 101,n,Dial(SIP/secondpeer,20)

OK. I think I’ve got the test set up right. In my extensions.conf I’ve got:

[code][users]
exten => 100,1,Answer()
exten => 100,n,Dial(SIP/JP_Android,20)

exten => 101,1,Answer()
exten => 101,n,Dial(SIP/iMac,20)[/code]

And that’s included in my [gvjp] context, which both SIP phones are members of.

From JP_Android I can call 101, and I see X-Lite on my iMac ring, and I can answer (I’m in through VNC though, so I can’t actually hear/say anything, but I’m sure I got the dog’s attention).

When I try to call 100 on X-Lite, I get the same results as when trying PTSN calls to my GV number.

So there must be something I’ve got screwed up either in my SIP declaration in sip.conf for the Android, or in the SIPDroid configuration itself.

Edit: I was able to just call the 100 extension. I changed the domain on X-Lite from the internal IP address of the Asterisk server to the fqdn of my domain. The call went through.

Strange behavior now: I still get the ‘call ended’ screen on SIPDroid for a second. The caller ID for it is showing up as ‘iMac’. This is even when I call from my work desk!

Just changed my inbound GV context to dial the iMac instead of the Droid, and voila! the call goes through. The iMac X-Lite config is set to use my public IP, so it should be NAT’d, and that’s working. Still no on the Droid, but I’m still tinkering.

Wish I could help w/ SIPDroid, but I’m an iPhone.

After all this, I think I got it.
I exited out of SIPDroid, went to the Android market and downloaded 3CXPhone for Android.

Everything works.

I think SIPDroid has aligned itself more and more with PBXes.org, that maybe their implementation of SIP has changed.
I think I’m actually good to go now.

Thank you so much for all your help!!!

Yay :smile:

I thought I was out of the woods, but there’s yet another issue! So now I’m on CSipSimple for Android, which so far appears to be the best. But this issue happened on 3CX as well.

I call from my work to my GV number. I see Asterisk answer, wait, send DTMF(1) then call SIP/JPDroid. My droid rings. I see the caller ID (a little ugly, I think it grabs it from the SIP message => +1XXXXXX5477@voice.google.com/srvres-MTAuMTQzLjguMTM6OTg1Mg==).

I answer it on the Droid. The Droid says connected, and the call timer starts incrementing. But on the handset of my PTSN work phone, it’s still ringing! And eventually goes to my GV voicemail. It’s like there’s some disconnect at the final handoff. Asterisk and the SIP device both appear to think the call has been established, yet the caller (PTSN work phone) just keeps getting the ringer, then finally to voicemail.

The weird thing though, is that occasionally I’ll actually get the call connected, and have 2-way audio. But if I try calling say, 10 times, maybe once it will work, and the other 9 times will have the described result.

Very frustrating to be this close!