| Summary: | ASTERISK-08953: [patch] Early bridge is performed on channels with incompatible codecs when directrtpsetup=yes | ||
| Reporter: | Marcel Barbulescu (marcelbarbulescu) | Labels: | |
| Date Opened: | 2007-03-06 21:16:38.000-0600 | Date Closed: | 2007-06-30 09:20:07 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/CodecHandling |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) rtp.patch ( 1) verbosedebug.txt | |
| Description: | Asterisk SVN-branch-1.4-r58168 running on CentOS 4.4 with kernel 2.6.9-42.0.10.EL. I know that "directrtpsetup" is an experimental feature and it creates problems when the destination responds with codecs that do not match the source codecs. However, Asterisk shouldn't try the direct rtp setup if it knows for sure that the two parties have no common codec and transcoding is necessary. Currently, with "directrtpsetup=yes" and the destination sending back early media, early bridge is performed even if the two parties have no common codec. The destination sends early media to the source with a codec that is unknown to the source. ****** ADDITIONAL INFORMATION ****** Please note that the IPs and phone numbers in the trace file are not real. | ||
| Comments: | By: Joshua C. Colp (jcolp) 2007-03-07 11:55:13.000-0600 Can you please try 1.4 as of revision 58240? It should be a bit smarter. By: Marcel Barbulescu (marcelbarbulescu) 2007-03-07 13:24:45.000-0600 The destination is still invited with the source IP (not the Asterisk IP) in SDP and with the g729 codec which is not supported by the source. After the 183 comes in from the destination, the 183 that is generated to the source is having the IP of the Asterisk box and the right codecs (supported by the source) in the SDP. So the second part looks good. If the Asterisk would send its own IP in the SDP of the original invite I assume all would be great. By: Marcel Barbulescu (marcelbarbulescu) 2007-03-07 21:03:08.000-0600 file: I've added a patch along the lines you did to solve the second part of the problem. By: Joshua C. Colp (jcolp) 2007-03-08 12:06:48.000-0600 Okay, I've put in the last part in 1.4 as of ervision 58436 and trunk as of revision 58437. Where do we stand on this now? By: Marcel Barbulescu (marcelbarbulescu) 2007-03-08 13:36:57.000-0600 Problem solved. All looks good. You can probably close 8152 too. By: Serge Vecher (serge-v) 2007-03-08 14:05:25.000-0600 thanks for testing and the patch! | ||