[asterisk-dev] Dial() with s or m option produces million incompatible codec warnings

[Kirill Katsnelson]

Some relation to #14504 is certain. This is 1.8.3-rc2. 1.6.2 does not 
have this problem.

I am fighting millions (no exaggeration) warnings that read

WARNING[27712]: chan_sip.c:6047 sip_write: Asked to transmit frame type 
slin, while native formats is 0x4 (ulaw) read/write = 0x4 (ulaw)/0x4 (ulaw)

The scenario is like this:
* A call is originated via AMI Originate, channel Local/s at local to s at remote
* s at local dialplan is executed, places a call to agent via a Queue. this 
is the "local" end.
* after it is connected, s at remote is executed, and calls a Dial(). This 
is a "remote" end.

If the Dial options include m() or r(), I am getting the warnings. If 
neither is present, none. Warnings cease as soon as the remote end ACKs.

RTP debug shows RTP traffic to and from the local endpoint, and packets 
from the remote endpoint. None send to the remote endpoint.

Debug log is somewhat peculiar: the warnings start after Asterisk send 
and INVITE but before it even receives any response from the remote with 
an SDP. So there is no known destination to send RTP to.

The sequence of logged events is thus (this is with the m() option):
INVITE is sent out.
VERBOSE[25086] app_dial.c:     -- Called remote/...
VERBOSE[25086] res_musiconhold.c:     -- Started music on hold..., on 
SIP/local-00000e9a
DEBUG[25086] channel.c: Scheduling timer at (50 requested / 50 actual) 
timer ticks per second
VERBOSE[25086] app_dial.c:     -- SIP/local-00000e9a requested special 
control 20, passing it to SIP/remote-00000e9b
DEBUG[25086] res_rtp_asterisk.c: Setting the marker bit due to a source 
update
WARNING[25086] chan_sip.c: Asked to transmit frame type slin, while 
native formats is 0x4 (ulaw) read/write = 0x4 (ulaw)/0x4 (ulaw)
SIP/2.0 100 Giving a try
SIP/2.0 183 Session Progress
etc.

Local end hears MOH from the m() option or generated indication from 
r(). I have no idea why should we send anything to the remote end at 
all. Provided we do not even know where to send.

Any word of advice on how to track it down is appreciated.

In particular, why the channels are not made compatible if either option 
is present (from dial.c, by way of the patch in #14504):

if (!ast_test_flag64(outgoing, OPT_MUSICBACK | OPT_RINGBACK)) {
   ast_deactivate_generator(in);
   /* If we are calling a single channel, and not providing ringback or 
music, */
   /* then, make them compatible for in-band tone purpose */
   ast_channel_make_compatible(outgoing->chan, in);
}

  -kkm