Asterisk is ignoring the codec offer of the caller. Asterisk is
always sending the whole codec list inside 200 OK (on invites),
which should be just a subset of that what is received before within
the dialog initiating invite.
Workaround:
Try "disallow=gsm"
regards,
Michael
Bill Michaelson wrote:
>I am trying to muddle my way tthrough getting something - actually
>anything to work - with Asterisk. I've acquired a Grandstream phone and
>I've got * on a Red Hat 9 box. I've gotten to a point where I can see
>(via ethereal) that the phone REGISTER's successfully with asterisk, and
>then I try to dial into voicemail. This is what I observe in the packet
>trace...
>
>GS: INVITE -> *
>*: Status 100 (Trying) -> GS
>*: Status 200 (OK with session description) -> GS
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
-------------------------
Thanks for that hint. I see what you mean. When configured for FWD,
the GS does indeed send an ACK at an equivalent point in the protocol.
But no, the GS does not send an ACK when configured for my * box. 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. 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).
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? Shouldn't it wait?
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...
With FWD, the OK message lists 3 Media Formats:
Media Description, name and address (m): audio 10496 RTP/AVP 0 8 101
Media Type: audio
Media Port: 10496
Media Proto: RTP/AVP
Media Format: 0
Media Format: 8
Media Format: 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
But with the local box, it lists one other - note the addition of GSM...
Media Description, name and address (m): audio 16708 RTP/AVP 3 0 8
101
Media Type: audio
Media Port: 16708
Media Proto: RTP/AVP
Media Format: 3
Media Format: 0
Media Format: 8
Media Format: 101
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Don't see much else different in the packets.
It might also be relevant that the FWD connection, which works
successfully,
is through a firewall with NAT.
Still fishing... thanks for your attention - much appreciate not being
alone
here!
|