asterisk users - Apr 2011 - Asterisk codec negotiation and canreinvite=no

Hi all, 

I realise that asterisk's codec negotiation has been discussed in 
the past multiple times. What I haven't been able to understand is 
how asterisk decides which video codecs to advertise to the other 
end  when canreinvite=no in sip.conf and the initial caller
doesn't support video. 

My tests are quite simple, I use an asterisk with 4 peers all on the 
same LAN. My sip.conf looks like that:

[general]
bindport=1628
videosupport=yes
limitonpeers = yes
sendrpid = yes
trustrpid = no
disallow=all
allow = gsm # 3
allow = alaw # 8
allow = ulaw # 0
allow = g722 # 9
allow = g726 # 111
allow = h263 # 34
allow = h263p # 98
allow = h264 # 99

[peerA]
type=friend
secret=kokolala
nat=no
host=dynamic
canreinvite=no
context=koko
dtmfmode=rfc2833
disallow=all
allow = gsm
allow = alaw
allow = ulaw
allow = g722
allow = g726
allow = h263
allow = h263p
allow = h264
qualify=no

<snip more similar peers>

For clients I use GXP-2000,  X-Lite, Telephone and Linphone and in all my 
tests, one client was calling the other. 

When Linphone and X-lite are the initial callers, asterisk 
correctly  adveritises h263 and h263p and not h264. 

GXP-2000 invites for instance X-lite

Initial INVITE  || Asterisk's INVITE
------------------------------------------
        18             ||           8
        97             ||           3
          0             ||           0
          8             ||       111
          4             ||         
          9             ||         34
                         ||         98
                         ||         99

What I can't understand is:

1) Since in the initial INVITE there are no video codecs, why does
asterisk decide to  adveritise video codecs when inviting the other
client. 

2) When the initial INVITE comes from Telephone.app (no video), 
in version 1.6.2.17.2 asterisk advertises h263p (98) only. 
In version 1.8.3.2 (same configuration), using the same client,
asterisk advertises all video codecs found in sip.conf (h263, h263p, h264). 
 
Is this the expected behavior? 

The problem  raised here is that, in a production system, with 
videosupport=yes, for an audio-only call,  asterisk will send invites 
where the SDP will have at least 1 video codec,  but it may 
have 3 as well. 

This may lead to some buggy clients not to accept the call (with 488), 
but I've noticed some cases where a callee was behind NAT,
an INVITE with one video codec would me forwarded properly 
to the callee, but another INVITE with 3 video codecs, would 
never reach the callee, probably because it was never forwarded by 
the router (I still haven't been able to figure this out).

Cheers, 

-effie

On 11-04-11 10:26 AM, Effie Mouzeli wrote:
> This may lead to some buggy clients not to accept the call (with 488),
> but I've noticed some cases where a callee was behind NAT,
> an INVITE with one video codec would me forwarded properly
> to the callee, but another INVITE with 3 video codecs, would
> never reach the callee, probably because it was never forwarded by
> the router (I still haven't been able to figure this out).
>
The code you are talking about underwent a complete rewrite [1] and has 
already been merged into trunk[2].  Not that it helps you now, but you 
may want to try testing with trunk (will become Asterisk 1.10) and see 
if you have the same issues.

This is one of the major milestones for Asterisk 1.10, and I'm sure any 
feedback in testing will be much appreciated.

[1] https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
[2] http://svn.digium.com/view/asterisk?view=revision&revision=306010
-- 
Paul Belanger
Digium, Inc. | Software Developer
twitter: pabelanger | IRC: pabelanger (Freenode)
Check us out at: http://digium.com & http://asterisk.org