Summary:	ASTERISK-07778: codec capabilities are not checked on call legs when making an Attended xfer (REFER)
Reporter:	chankm (chankm)	Labels:
Date Opened:	2006-09-20 01:29:34	Date Closed:	2006-10-26 01:23:08
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) consolelog_TransferProblem ( 1) consolelogs2_TransferProblem ( 2) sip.conf
Description:	According to the latest trunk for chan_sip.c, I think there are some problems in the handling of codecs for an Attended Transfer. for example, given the following scenario : sip1 <--> Asterisk <---> sip2       ^ sip3 <---------| sip1 supports g711 and g729 only sip2 supports g711 and g729 only sip3 supports g729 only sip1 establishes a call to sip2 using g711. sip2 holds the call. sip2 then establishes a call to sip3 using g729. When sip2 presses the "Transfer" button, sip1 and sip3 cannot get connected because of codec mismatch. According to the codes, Asterisk doesn't send an INVITE to sip1 to force sip1 to change its codec to g729. As such, it is impossible for sip1 to talk to sip3 using g729. The call between sip1 and sip3 is dropped. Does anyone have any comments on this problem ? Thank you.
Comments:	By: Serge Vecher (serge-v) 2006-09-20 08:51:38 1. is canreinvite setting set to 'yes' for all peers? If yes, then please provide the console capture with SIP debug enabled as per the following instructions: 1) Prepare test environment (reduce the ammount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterik. 4) Enable SIP transaction logging with the following CLI commands: set debug 4 set verbose 4 sip debug 5) Save complete console log to file and _attach_ said file to the bug. By: chankm (chankm) 2006-09-20 21:04:06 Test-Bed setup for Attended Transfer : 2007 <--> Asterisk <--> 2003                ^ 2006 <-------| 2007 supports g729 and g711 only 2003 supports g729 and g711 only 2006 supports g729 only canreinvite = yes for 2003, 2006, 2007 Asterisk-1.2.12.1 is used for the testing Test Scenario : a) 2007 dials 2003 to establishe a call to 2003 using g711 b) sip.conf is changed such that 2003's preferred codec is g729 c) "sip reload" is executed at Asterisk d) 2003 holds call e) 2003 dials to 2006 to establish a call to 2006 using g729 f) 2003 presses "Transfer" button g) Call between 2006 and 2007 is dropped By: Serge Vecher (serge-v) 2006-09-21 08:34:54 as specified in documentation for 'canreinvite' option, it will not work with a nat'ted peer. Why do you have 'nat' for these peers anyway, since they are on the same net with the Asterisk server? By: chankm (chankm) 2006-09-21 20:08:46 I have configured the nat=no for all peers. but 2006 could not connect to 2007. I have attached the logs. According to the logs, the Bridge failed for 2006 and 2007 because of incompatible codecs. By: Serge Vecher (serge-v) 2006-09-22 09:37:59 ok, here is my analysis of what's going on: 1. the 2007 <-> 2003 call is in 'ulaw', as that's the preferred codec for both; 2. the 2003 <-> 2006 call is in 'g729', as both support it. When 2003 REFERs (transfers) its call to 2006 back to 2007, chan_sip does so in quite a "brute" manner, i.e. without checking the capabilities of both peers and relying on the core to do the bridging properly, and the core will just transcode if calls use different codecs... But since you don't have g729 license(s), the transcoding fails, hence these warnings: Sep 22 08:56:32 WARNING[18103] channel.c: Unable to find a codec translation path from g729 to ulaw Sep 22 08:56:32 WARNING[18103] channel.c: Unable to find a codec translation path from g729 to ulaw By: Serge Vecher (serge-v) 2006-09-22 09:43:44 given the above analysis, you have a couple of options: 1. move allow=g729 above allow=ulaw for peers 2007 and 2003. This will cause the g729 codec to be the preferred one and all calls will be established with g.729 accross the board. 2. try Asterisk 1.4-beta02 to see if rewritten REFER-handling code handles the situation more gracefully. 3. try the code in bug ASTERISK-4703, which makes codec negotiation in Asterisk a bit more intelligent. By: chankm (chankm) 2006-09-22 20:32:14 Thanks for your reply. I was hoping that the Transfer would be transparent in that there is no need for reconfiguration of sip.conf, assuming the preferred codec of 2007 and 2003 is ulaw. I have also tried 1.4-beta02 and a patched 1.2.12. Both have the same Transfer Problem. When I refer to the codes, there isn't any provision to send an INVITE explicitly to change the codec of the transferee. Could you tell me if there is any discussion to include this INVITE in future releases ? By: Serge Vecher (serge-v) 2006-09-25 08:24:55 chankm: thanks for checking -- I'm not aware of any such discussion; you may want to email the Asterisk-dev mailing list with this question mentioning this bug #, to see if any developer is working on this feature independently. By: Olle Johansson (oej) 2006-10-25 14:42:18 This is an interesting bug. We never send an Invite to change codec, but when setting up the connection between sip3 and sip1, there should be a translation path from G711 (which is the current call leg to sip1) and G.729 (the call leg to SIP3). Asterisk is actually telling you that we can't fix a translation path and make these channels compatible Sep 22 08:56:32 DEBUG[18103] rtp.c: Channel codec0 = 4 is not codec1 = 256, cannot native bridge in RTP. Sep 22 08:56:32 WARNING[18103] channel.c: No path to translate from SIP/2007-08c43d88(4) to SIP/2006-08c5cf58(256) Sep 22 08:56:32 WARNING[18103] channel.c: Can't make SIP/2007-08c43d88 and SIP/2006-08c5cf58 compatible - Do you have any g.729 licenses in this server? By: chankm (chankm) 2006-10-26 01:04:15 I do not have any g.729 licences in the server. I think it would be great if Asterisk could generate the Invite message to change the codec since sip1 supports g729. Ideally, sip1 and sip3 should talk and there should not be a need to use g.729 licence in this situation. By: Olle Johansson (oej) 2006-10-26 01:21:36 We can't do that. The re-invite is a secondary optimization. Since the call path always start through Asterisk (we're not a proxy you know), the call has to be able to go through your Asterisk. In this case, it can't since there's no G.729 codec license available. This is not a bug. By: Olle Johansson (oej) 2006-10-26 01:23:07 Caused by lack of G.729 licenses for transcoding. Asterisk reported correctly to the console. We all wish for a new codec negotiation system. In 1.4, we've improved a bit but I don't think it will change this problem. Sorry. Not a bug report any more, more of a feature request for future redesigns. Thanks for reporting it to us.