[asterisk-bugs] [Asterisk 0009815]: [patch] major fix for SIP video codec negociations

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=9815 
====================================================================== 
Reported By:                neutrino88
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   9815
Category:                   Channels/chan_sip/Video
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.4 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             05-27-2007 09:45 CDT
Last Modified:              11-04-2007 06:40 CST
====================================================================== 
Summary:                    [patch] major fix for SIP video codec negociations
Description: 
I was trying to make a video call between two SIP phone having the save
video codec but supporting different (and distinct) audio codecs. I found
out that Asterisk codec negociation is very broken when video is involved
and I found 4 bugs. 

- bug 1 - A call B, A has codecs h.263 + ilbc, b has codec h.263 + ulaw

On asterisk 1.4.4, call fails with trace:

     -- Call on SIP/2005-090ef910 left from hold
 [May 26 05:46:23] DEBUG[923]: devicestate.c:303
__ast_device_state_changed_literal:  Notification of state change to be
queued on device/channel SIP/2005-090ef910
     -- SIP/2005-090ef910 answered SIP/2006-090f7b40
 [May 26 06:34:33] DEBUG[3940]: channel.c:2874 set_format: set_format()
channel SIP/2006-09d189f8 audip from 00000000 to 00080400 in dir. read
 [May 26 05:46:23] WARNING[923]: channel.c:2882 set_format:  Unable to
find a codec translation path from unknown to unknown
 [May 26 05:46:23] WARNING[923]: channel.c:3234
ast_channel_make_compatible:  Unable to set read format on channel
SIP/2006-090f7b40 to 524288
 [May 26 05:46:23] WARNING[923]: app_dial.c:1628 dial_exec_full:  Had to
drop call because I couldn't make SIP/2006-090f7b40 compatible with
SIP/2005-090ef910


Cause: function make_compatible_channel() lookup for translator with
composite (audio+video) formats
Fix: separate processing of audio translation and video translation


- bug 2 - B calls A. Same codecs as above

Assuming fix 1 is applied on ast 1.4.4, call fails with a similar message
Cause: in newly created outging channel, jointcapabilities is not
initialized properly.



- bug 3 - A calls B. A has h.263 + ulaw + ilbc configured in sip.conf but
actually A supports only h.263 + ulaw, B has h.263 + ilbc in sip.conf
 
On ast 1.4.4, When B anwers,A receives 200 OK with h.263 + ilbc !!! where
it shoud be h.263 + ulaw
Cause: bug in process_sdp when checking joint capabilites. COndition for
disjoint audio codec does not cause reconfiguration of native format.


- bug 4 - B call A. A has h.263 + ulaw, B has h263, h263+, ilbc

On ast 1.4.4, when A answers, A receives 200 OK with both video codecs
!!!!
Cause: there is no mechanism to pass codecs negocialted from outbound
channel to back inbound channel.
Fix: added sip_setoption and used ast_channel_option to pass the
negociated codec back. Implemented it inside
make_channel_compatible() in channel.c. Restricted it to SIP chans but can
be extended easily to other tech

I included a patch that correct this behavior. I sincerly hope that it
will make its way into Ast because it corrects loads of problems. 


On the more philosofical level, we have in my view a specification issue
at stake. I mean that codec capabilities for modern protocols like SIP,
IAX, Gtalk, H.323 and even H.324m that are able to support codec
negociation should not be specified at the user (or peer) level. It should
be left to both end to negociate. If Asterisk is to be used as a video IVR,
then, we would need to add the ability to specify a capability per
extention.

Emmanuel 
http://www.ives.fr
====================================================================== 

---------------------------------------------------------------------- 
 avalentin - 11-04-07 06:40  
---------------------------------------------------------------------- 
I cannot decompress your patch. Could you check it or send to me via email:
a.valentin at ddimension.net. 
Thanks 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-04-07 06:40  avalentin      Note Added: 0073057                          
======================================================================