Google Chat user as trusted caller.Obi cant understand digits entered by caller

[earthtoobi]

i have 2 Obi's connected in different geographical locations with google voice configured in both.
have added google user 1(obi #1) as trusted caller in obi number 2.
when i call device 2 from device 1 as **1<googleuser2>,i get the attendant.
the Problem now is that any pressing of 1,2,3 etc does not seem to be recognized on the other end.
this works if the connection is via obitalk network.
i wondered if it was DTMF related and tried changing from Auto to Inband. still same issue.
wondering if anyone else got it to work.

Question 2:
i was looking at libjingle details:
http://code.google.com/apis/talk/libjingle/important_concepts.html#ssl
and was wondering why the calls made the way explained above always used a relay on my side and was not a P2P. i could see that i was connecting directly to destination internet address while my IP was a relay Ip as seen from device 2.

in my setup, device 1 is behind a firewall/router and device 2 is directly on the internet.
do i need ICE/STUN enabled on device 1 for p2p connection...any pointers are appreciated...

[Stewart]

If the AA receives no tones, after three retries it should connect to the "no input" number, by default the Phone port.  Upon answering that, if there is no audio, the problem is obviously unrelated to DTMF.  If audio is ok, you can try pressing buttons at the calling end and listening for DTMF on the phone.

Why do you care about the GV path, since you already have the OBiTALK path working fine?

I know little about Jingle, but why do you care about the relay?  Latency?  Privacy?  Because of subtle issues associated with NAT port translation, a relay approach is usually more reliable and robust.  It also enables the provider to transcode, monitor quality, etc.  For example, Vonage and Callcentric always proxy the media.  Low cost providers often don't, mostly to economize on their bandwidth requirements.

[earthtoobi]

If the AA receives no tones, after three retries it should connect to the "no input" number, by default the Phone port.  Upon answering that, if there is no audio, the problem is obviously unrelated to DTMF.  If audio is ok, you can try pressing buttons at the calling end and listening for DTMF on the phone.

@Stewart:  the issue is that DTMF is not recognized. that is the first part of issue.

Why do you care about the GV path, since you already have the OBiTALK path working fine?

@Stewart: we have seen that Obitalk voice network may not be very reliable with many unscheduled downtimes. GoogleChat that way is more reliable.also, SIP is blocked in the country where Obi is deployed

I know little about Jingle, but why do you care about the relay?  Latency?  Privacy?  Because of subtle issues associated with NAT port translation, a relay approach is usually more reliable and robust.  It also enables the provider to transcode, monitor quality, etc.  For example, Vonage and Callcentric always proxy the media.  Low cost providers often don't, mostly to economize on their bandwidth requirements.

@Stewart: latency/privacy is the main reason.

i wonder if anyone has tried calling obi-obi via GoogleChat (in the format: **1<targetobigoogleuser>)