[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:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13076
Category:                   Channels/chan_sip/CodecHandling
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
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 04: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.

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

---------------------------------------------------------------------- 
 (0092211) putnopvut (administrator) - 2008-09-09 04:05
 http://bugs.digium.com/view.php?id=13076#c92211 
---------------------------------------------------------------------- 
A quick look through the code suggests what you have probably guessed to be
the case. Asterisk appears to be basing the codecs offered in the re-invite
on what was offered in the SDP of the initial INVITE received.

This actually makes sense to some degree. If both peers are capable of
communicating using the same codec and no Asterisk media features are
needed for the call, then Asterisk should send REINVITES to get the
endpoints to communicate directly using their mutually available codecs.

The problem appears to be that once Asterisk has surmised that both peers
are capable of sending G.729, it doesn't follow through properly with the
SDP's offered in the REINVITES. The first REINVITE is sent to Device B with
G.729 offered in the SDP. The second is sent to Device A with ... no
codecs. None. This is why Device A responds with a 488. The T.38 error
message is Asterisk's attempt to figure out why it got a 488 on a reinvite
and is inaccurate in this scenario.

In my opinion, while it does make sense to determine native bridge
capabilities based on what the peer is capable of, it does not make sense
to do this if we're only going to offer codecs configured in sip.conf in
the REINVITEs. I also, however, am curious why the sip.conf entry for peer
A would not match the codecs that device A is capable of using. I suppose
there are sane reasons why you're doing this though.

I see two potential fixes for this. One is to change the logic used when
sending the REINVITEs so that we offer the negotiated jointly capable codec
to both peers (in this case G.729). The problem with this approach is that
it could possibly violate the codec options placed in sip.conf. In your
case, we would end up sending an SDP offering G.729 to a peer which is
defined to only allow alaw. The other possible change is to use the codecs
we are capable of using when communicating with the peer when determining
if a native bridge is possible. This has the advantage of using only the
codecs specified in sip.conf, but in your case for instance, we would lose
the native bridge that we know is possible and add a transcoding burden to
Asterisk for this call. 

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