[asterisk-dev] Multiple codecs on SDP answer if SIP_CODEC variable is used

[Saúl Ibarra Corretgé]

On Sun, Nov 7, 2010 at 11:31 AM, Saúl Ibarra Corretgé <saghul at gmail.com> wrote:
> Hi,
>
> I'm experiencing some unexpected (at least to me) behavior when the
> SIP_CODEC variable is set and I'd like some input before posting an
> issue.
>
> Test case: assume we have the following configuration:
>
> [telf](!)
> type=friend
> secret=1234
> disallow=all
> allow=g722
> allow=alaw
> allow=ulaw
> allow=gsm
> dtmfmode=rfc2833
> context=saghul-test
> host=dynamic
>
> and
>
> [saghul-test]
> exten => 12346,1,NoOp()
> same => n,Set(__SIP_CODEC=g722)
> same => n,Answer
> same => n,Wait(1)
> same => n,MusicOnHold(default)
>
> If a user dials 12346 *with* G722 on his SDP offer the answer
> generated by Asterisk contains a single codec: G722, all ok:
>
> v=0
> o=root 542332501 542332501 IN IP4 192.168.99.53
> s=Asterisk PBX SVN-branch-1.8-r294084
> c=IN IP4 192.168.99.53
> t=0 0
> m=audio 15168 RTP/AVP 9 101
> a=rtpmap:9 G722/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
>
> However, if the SDP offer *doesn't contain* G722, Asterisk prints a
> log line saying that both parties don't support G722 so it won't be
> used. That's fine, but the SDP answer generated contains all the
> codecs that were offered and are allowed in the peer definition:
>
> v=0
> o=root 911458123 911458123 IN IP4 192.168.99.53
> s=Asterisk PBX SVN-branch-1.8-r294084
> c=IN IP4 192.168.99.53
> t=0 0
> m=audio 16716 RTP/AVP 8 0 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
>
>
> Is this intended? I would expect the answer to contain a single codec,
> it being the next one that could possibly be used. Is this a bug or a
> feature? :-)
>
>
> Thanks and regards,
>

Hum, seems like you always find some answer just after sending the
email :-S I would have sworn that if that variable wan't set Asterisk
answered with a single codec always, but that doesn't seem to be the
case, so the behavior is consistent.

Sorry for the noise,

-- 
/Saúl
http://saghul.net | http://sipdoc.net