[Asterisk-Users] Re: asterisk-grandstream call

[Michael Koehler]

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!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20040211/4a7620b4/attachment.htm