[asterisk-bugs] [Asterisk 0013076]: Re-Invite occurs eventhough the codecs are incompatible.
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Sep 9 08:59:25 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 08:59 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.
======================================================================
----------------------------------------------------------------------
(0092244) tbelder (reporter) - 2008-09-09 08:59
http://bugs.digium.com/view.php?id=13076#c92244
----------------------------------------------------------------------
Thanks!
Tested your patch in 2 ways.
Test 1:
- Peer A offers alaw/g729, Peer B offers g729
- Peer A is configured in sip.conf to allow only alaw
- Peer B is configured in sip.conf to allow only g729
In this case Asterisk doesn't send a REINVITE, but transcodes the call,
which is correct.
Test 2:
- Peer A offers alaw/g729, Peer B offers g729
- Peer A is configured in sip.conf to allow g729 and alaw
- Peer B is configured in sip.conf to allow only g729
In this case Asterisk sends a REINVITE and offers in both invites to peer
A and B g729 as codec, which is also correct.
So the patch is working for us. But I have no overview to determine the
effects of this patch. Asterisk now gets the codecs from what is allowed
instead of which codecs are offered by the peer. Am i correct?
Issue History
Date Modified Username Field Change
======================================================================
2008-09-09 08:59 tbelder Note Added: 0092244
======================================================================
More information about the asterisk-bugs
mailing list