[ previous ] [ next ] [ threads ]
 To :  yate@v...
 From :  Pete Kelly <pkelly@g...>
 Subject :  Yate codec behaviour
 Date :  Thu, 29 Apr 2010 12:56:20 +0100
I have been using the 'formats' parameter in yate events to decide
upon which codec to use for calls.

However  I have noticed there is an irregularity which causes yate to
not process incoming audio if no SIP 183 is sent:

Scenario1)

Incoming call.execute into Yate, codec list is "g729,alaw,mulaw"
dispatch of chan.attach to send early media (ringing), including the
formats parameter "g729,alaw,mulaw"
dispatch of call.progress
dispatch of call.answered, including the formats parameter "g729,alaw,mulaw"

In this scenario everything works as it should and I see an output in
the Yate log just before the SIP 183 is sent of
 DataTranslator::attachChain [0x80c4fc8] 'g729' -> [0x80a87f8]
'g729' succeeded


Scenario2)
Incoming call.execute into Yate, codec list is "g729,alaw,mulaw"
dispatch of call.progress
dispatch of call.answered, including the formats parameter "g729,alaw,mulaw"

In this scenario Yate does not see any incoming audio (in this case I
was looking for rfc2833 DTMF tones and verified they were being sent
to yate using tcpdump) and I see an output in the Yate log just before
the SIP 200 is sent:
 DataTranslator::attachChain [0x80a8740] 'g729' -> [0x80a86e0]
'(null)' not possible


In both scenarios Yate sends the correct SIP SDP content, however in
the latter it seems to not store internally the codec it should be
using.

Does anyone else have experience of this, is it expected behaviour? I
have coded round the problem by always sending a chan.attach even if
there is no need but it seems to me that it should work even if only a
200 is sent.

Pete