<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Asterisk is ignoring the codec offer of the caller.&nbsp; Asterisk is<br>
always sending the whole codec list inside 200 OK (on invites),<br>
which should be just a subset of that what is received before within<br>
the dialog initiating invite.<br>
<br>
Workaround:<br>
&nbsp;Try "disallow=gsm"<br>
<br>
regards,<br>
<br>
Michael<br>
<br>
Bill Michaelson wrote:<br>
<blockquote type="cite" cite="mid40295A6D.8010909@cosi.com">
  <title></title>
  <title></title>
  <br>
  <br>
  <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>
</blockquote>
</body>
</html>