[asterisk-bugs] [Asterisk 0013076]: Re-Invite occurs eventhough the codecs are incompatible.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13076 
====================================================================== 
Reported By:                ramonpeek
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   13076
Category:                   Channels/chan_sip/CodecHandling
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           1.4.21 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-07-15 06:27 CDT
Last Modified:              2008-09-09 10:05 CDT
====================================================================== 
Summary:                    Re-Invite occurs eventhough the codecs are
incompatible.
Description: 
Re-invite occurs eventhough the codecs are incompatible.
See these steps to reproduce;

Device A accepts/offers codecs g711 & g729a (AudioCodes Mediant 1000)
Peer A in Asterisk only supports codec g711a 
Peer B in Asterisk only supports codec g729a
Device B accepts/offers codec g729a (Snom Phone)

A call from device A is routed through Asterisk to device B.
Device B answers and then Asterisk sends a re-invite without a codec!!?
But why, The codecs don't even match!
Asterisk then prints-out the CLI-Error:
"ERROR[31381]: chan_sip.c:12326 handle_response_invite: Got error on T.38
re-invite. Bad configuration. Peer needs to have T.38 disabled."



Note:
If canreinvite is set to no the problem obviously does not occur.
And if peer a is set to allow G711a AND G729a the problem also does not
occur.

 
====================================================================== 

---------------------------------------------------------------------- 
 (0092248) putnopvut (administrator) - 2008-09-09 10:05
 http://bugs.digium.com/view.php?id=13076#c92248 
---------------------------------------------------------------------- 
Great! Thanks for the tests. I'm glad everything is working as expected. To
answer your question of "Am I correct?" You are mostly correct and may in
fact be fully correct. Here's the explanation for you just in case.

Asterisk maintains three "capabilities" variables per call  leg:
 * ourcapabilities - What is defined in sip.conf for the peer
 * peercapabilities - What was offered in the SDP by the peer
 * jointcapabilities - A bitwise AND of the above two variables

The old (and broken) version was using peercapabilities of both call legs
to determine if they shared common codecs. Then, when the time came to send
a REINVITE, it may be that because the jointcapabilities of a call leg does
not include the codec that was determined to be used for the native bridge,
Asterisk would end up sending a REINVITE with no codec at all. This, as you
put it, should never happen.

The way used in the patch is to use the jointcapabilites of both call legs
to determine if they share common codecs. This way, we already know that
Asterisk has the capability of communicating using the negotiated codec
from the native bridge code. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-09 10:05 putnopvut      Note Added: 0092248                          
======================================================================