[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-08-2007 03:45 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
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0009066 Cannot make compatible if video codecs ...
====================================================================== 

---------------------------------------------------------------------- 
 rayjay - 11-08-07 03:45  
---------------------------------------------------------------------- 
I tried applying this patch to 1.4.13 and although it helped resolve some
of the video related codec issues - it seems to have broken some codec
negotiation on standard voice calls so I had to back it out.  I have a SIP
trunk to the PSTN for which I use G711 alaw and I have clients using
ilbc/g729 etc. and after applying this patch calls started failing.  It
seems the session progress message and OK messages did not match codec wise
and the client rejected the OK which was repeatedly retransmitted and meant
the call did not setup correctly and we ended up with one way audio before
the call was finally torn down.

I'll try and get more info for you tomorrow, but it seems this patch
breaks a whole lot more than it fixes (at least in our case). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-08-07 03:45  rayjay         Note Added: 0073369                          
======================================================================