<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<title></title>
       <br>
 <br>
 
<pre wrap=""><div class="moz-txt-sig"></div></pre>
 
<blockquote type="cite">   
  <pre wrap=""><span class="moz-txt-citetags">&gt;</span>I am trying to muddle my way tthrough getting something - actually 
<span class="moz-txt-citetags">&gt;</span>anything to work - with Asterisk.  I've acquired a Grandstream phone and 
<span class="moz-txt-citetags">&gt;</span>I've got * on a Red Hat 9 box.   I've gotten to a point where I can see 
<span class="moz-txt-citetags">&gt;</span>(via ethereal) that the phone REGISTER's successfully with asterisk, and 
<span class="moz-txt-citetags">&gt;</span>then I try to dial into voicemail.  This is what I observe in the packet 
<span class="moz-txt-citetags">&gt;</span>trace...
<span class="moz-txt-citetags">&gt;</span>
<span class="moz-txt-citetags">&gt;</span>GS: INVITE -&gt; *
<span class="moz-txt-citetags">&gt;</span>*: Status 100 (Trying) -&gt; GS
<span class="moz-txt-citetags">&gt;</span>*: Status 200 (OK with session description) -&gt; GS
  </pre>
 </blockquote>
 
<pre wrap=""><!---->
Does the GS then send an ACK?  It should.  If it doesn't then this
probably means that it hasn't received the 200 response. (firewall
issue?)

If it is sending the ACK, then it is probably a codec issue, as has
been already mentioned.  GS doesn't always seem to do very well in
codec selection.

Doug
</pre>
 -------------------------<br>
 Thanks for that hint. &nbsp;I see what you mean. &nbsp;When configured for FWD, the 
GS does indeed send an ACK at an equivalent point in the protocol.<br>
 <br>
 But no, the GS does not send an ACK when configured for my * box. &nbsp;I suppose 
the * box is expecting it, because about one second later, the * box resends 
the 200 message - this in spite of the fact that has started spewing RTP
furiously. &nbsp;Both devices are on the same LAN, with no intervening firewall, 
and the OK ought to be visible to the GS (the packet even contains the expected 
destination MAC ID, derived earlier via ARP).<br>
 <br>
That makes two mysteries: 1) why doesn't the GS seem to see the OK? and 2)
why does * send the RTP stream in spite of the fact that it has not received
the ACK from the GS? &nbsp;Shouldn't it wait?<br>
<br>
Regarding codec selection, I see a minor difference between the FWD and the
local * box test cases, but I know nothing about the negotiation protocol...<br>
<br>
With FWD, the OK message lists 3 Media Formats:<br>
<br>
&nbsp;&nbsp;&nbsp; Media Description, name and address (m): audio 10496 RTP/AVP 0 8 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Port: 10496<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Format: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Format: 8<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Format: 101<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): fmtp:101 0-16<br>
<br>
But with the local box, it lists one other - note the addition of GSM...<br>
<br>
&nbsp;&nbsp;&nbsp; Media Description, name and address (m): audio 16708 RTP/AVP 3 0 8 101<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Type: audio<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Port: 16708<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Proto: RTP/AVP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Format: 3<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Format: 0<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Format: 8<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Media Format: 101<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): rtpmap:3 GSM/8000<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): rtpmap:0 PCMU/8000<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): rtpmap:8 PCMA/8000<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): rtpmap:101 telephone-event/8000<br>
&nbsp;&nbsp;&nbsp; Media Attribute (a): fmtp:101 0-16<br>
<br>
Don't see much else different in the packets.<br>
<br>
It might also be relevant that the FWD connection, which works successfully,
is through a firewall with NAT.<br>
<br>
Still fishing... thanks for your attention - much appreciate not being alone
here!<br>
<br>
 <br>
 
</body>
</html>