[asterisk-users] Two phones fail to agree on codec, asterisk at fault?

[martin f krafft]

Hi list,

I am faced by a situation where I am trying to make a softphone and
a Siemens C450IP talk to each other. Both are hooked up directly to
the same asterisk, in the same IP net. 

  - a softphone runs on 192.168.14.3
  - the C450IP is at 192.168.14.30
  - asterisk runs on the machine known as 192.168.14.1

I am running Asterisk 1.4.11, backported to Debian Etch by Xorcom.

If I set canreinvite=yes for both, everything works. However, I have
reason to use canreinvite=no for both. But if I do, then the two
phones fail to agree on a codec.

So calls are going via an asterisk bridge and the symptoms of my
problem are:

  1 if C450IP calls softphone, they can talk fine
  2 if softphone calls C450IP, voice only goes from C450IP to
    softphone, not the other way around.

I traced this down to the session description protocol, where there
is funky stuff going on with the supported codecs each peer
announces. Remember, asterisk is between them, and I set
disallow=all,allow=ulaw,allow=alaw in [global].

So in situation 1, when the C450IP calls the softphone, these codecs
are announced. 0 is ulaw, 8 is alaw, 111 is g726-32, 3 is gsm.

  C450IP to asterisk: 8, 0
  asterisk to softph: 8, 3, 0
  softph to asterisk: 8
  asterisk to C450IP: 8, 0

They both agree on 8 (alaw) and stuff is working, but it's already
curious how asterisk adds the 3 (GSM) in the second line and the
0 (ulaw) in the last.

In situation 2, no voice travels from the softphone to the C450IP,
and this is the dialog:

  softph to asterisk: 8, 0, 3
  asterisk to C450IP: 0, 8, 111
  C450IP to asterisk: 0
  asterisk to softph: 3, 0, 8

Again, notice how asterisk basically ignores what it was asked to
relay. In the end, the softphone settles for 3 (GSM) but the C450IP
chooses 0 (ulaw). Since the softphone has no problem decoding ulaw,
it can hear whatever the C450IP transmits, but it returns GSM
packets, which the C450IP can't decode, and therefore nothing comes
out of that phone.

What's going on here? From all I can tell, the clients do the right
thing, each selecting the first codec offered by asterisk (which
they support), but asterisk is going a bit lala here, isn't it?

First of all, why does it even bother with 3 and 111, given how
I disallowed them? And second, why does it *dare* to announce more
than what is available to the peer to which it relays?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"there are more things in heaven and earth, horatio,
 than are dreamt of in your philosophy."
                                                             -- hamlet
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080328/cc205604/attachment.pgp