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

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Sep 9 11:10:00 CDT 2008


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 11:09 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.

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

---------------------------------------------------------------------- 
 (0092259) svnbot (reporter) - 2008-09-09 11:09
 http://bugs.digium.com/view.php?id=13076#c92259 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 142079

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r142079 | mmichelson | 2008-09-09 11:09:58 -0500 (Tue, 09 Sep 2008) | 21
lines

When determining if codecs used by SIP peers allow
the media to be natively bridged, use the jointcapability
instead of the peercapability.

It seems that the intent of using the peercapability was to
expand the choice of codecs for the call to increase the
chances of being able to native bridge the channels. The 
problem is that if a codec were settled on for the native
bridge and that wasn't a codec that was configured to be used
by Asterisk for that peer, then Asterisk would send a 
REINVITE with no codecs in the SDP which is a bug no matter
how you slice it.


(closes issue http://bugs.digium.com/view.php?id=13076)
Reported by: ramonpeek
Patches:
      13076.patch uploaded by putnopvut (license 60)
Tested by: tbelder


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=142079 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-09 11:09 svnbot         Checkin                                      
2008-09-09 11:09 svnbot         Note Added: 0092259                          
======================================================================




More information about the asterisk-bugs mailing list