FS changes to transcoding after hold
Hello all, I have this Gigaset C430 SIP phone connected to FreeSWITCH 1.6.13. The phone it configured to offer G722 and G711. I use this on both internal and external SIP profile: <param name="inbound-codec-negotiation" value="greedy"/> <param name="inbound-late-negotiation" value="true"/> On the internal profile I also have the following, because the phone plays its own MOH so FS doesn't have to: <param name="disable-hold" value="true"/> So now I make an outbound call from the phone. It offers G722 and G711. FS offers both on the egress leg. On the egress G711 is negotiated. FS negotiates G711 with the Gigaset afterward. All fine. Next I push the R button on the phone and it sends a reINVITE to FS: INVITE sip:500@172.31.255.129:5892;transport=udp SIP/2.0 Via: SIP/2.0/UDP 172.31.255.132:5060;branch=z9hG4bK3acb589137e2c87caa513ddc3c92fb1d;rport From: <sip:301@172.31.255.129>;tag=3900142461 To: <sip:500@172.31.255.129;user=phone>;tag=6SX155B96H1pp Call-ID: 1793314766@172_31_255_132 CSeq: 4 INVITE Contact: <sip:301@172.31.255.132:5060> Proxy-Authorization: Digest username="301", realm="172.31.255.129", qop=auth, algorithm=MD5, uri="sip:500@172.31.255.129:5892;transport=udp", nonce="e68c4915-ef56-4f0a-ad28-f8c8535731c1", nc=00000002, cnonce="64b2c2e298dce6f8a5a79c06598c42f0", response="d9ab62f9b94158000dbf92dfe31a6a10" Max-Forwards: 70 User-Agent: C430A GO/42.240.00.000.000 Supported: replaces Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE Content-Type: application/sdp Content-Length: 143 v=0 o=301 5012 33 IN IP4 172.31.255.132 s=Mapping c=IN IP4 172.31.255.132 t=0 0 m=audio 5012 RTP/AVP 8 a=rtpmap:8 PCMA/8000 a=sendonly OK, so here it says it's going to send MOH and tells FS to listen. Next FS replies with 200-OK. FS does not send anything on the egress leg of this bridge (fine with me). SIP/2.0 200 OK Via: SIP/2.0/UDP 172.31.255.132:5060;branch=z9hG4bK3acb589137e2c87caa513ddc3c92fb1d;rport=5060 From: <sip:301@172.31.255.129>;tag=3900142461 To: <sip:500@172.31.255.129;user=phone>;tag=6SX155B96H1pp Call-ID: 1793314766@172_31_255_132 CSeq: 4 INVITE Contact: <sip:500@172.31.255.129:5892;transport=udp> Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIFY Supported: timer, path, replaces Session-Expires: 1800;refresher=uas Content-Type: application/sdp Content-Length: 195 v=0 o=root 1481307576 1481307578 IN IP4 172.31.255.129 s=root c=IN IP4 172.31.255.129 t=0 0 m=audio 10010 RTP/AVP 8 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - a=ptime:20 a=recvonly After a while I cancel the hold on the phone. Remember, G711 was negotiated on the initial bridge. INVITE sip:500@172.31.255.129:5892;transport=udp SIP/2.0 Via: SIP/2.0/UDP 172.31.255.132:5060;branch=z9hG4bK59938e08302f7ed7f1b3f1005aab27c3;rport From: <sip:301@172.31.255.129>;tag=3900142461 To: <sip:500@172.31.255.129;user=phone>;tag=6SX155B96H1pp Call-ID: 1793314766@172_31_255_132 CSeq: 5 INVITE Contact: <sip:301@172.31.255.132:5060> Proxy-Authorization: Digest username="301", realm="172.31.255.129", qop=auth, algorithm=MD5, uri="sip:500@172.31.255.129:5892;transport=udp", nonce="e68c4915-ef56-4f0a-ad28-f8c8535731c1", nc=00000003, cnonce="9bb91b66139de548b11790f4ccf2a838", response="12c5a33918a6890c0a675177c556239b" Max-Forwards: 70 User-Agent: C430A GO/42.240.00.000.000 Supported: replaces Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE Content-Type: application/sdp Content-Length: 223 v=0 o=301 5012 34 IN IP4 172.31.255.132 s=Mapping c=IN IP4 172.31.255.132 t=0 0 m=audio 5012 RTP/AVP 9 8 101 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 So the phone offers again G722 and G711. And now FS replies with this: SIP/2.0 200 OK Via: SIP/2.0/UDP 172.31.255.132:5060;branch=z9hG4bK59938e08302f7ed7f1b3f1005aab27c3;rport=5060 From: <sip:301@172.31.255.129>;tag=3900142461 To: <sip:500@172.31.255.129;user=phone>;tag=6SX155B96H1pp Call-ID: 1793314766@172_31_255_132 CSeq: 5 INVITE Contact: <sip:500@172.31.255.129:5892;transport=udp> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIFY Supported: timer, path, replaces Session-Expires: 1800;refresher=uas Content-Type: application/sdp Content-Length: 195 v=0 o=root 1481307576 1481307579 IN IP4 172.31.255.129 s=root c=IN IP4 172.31.255.129 t=0 0 m=audio 10010 RTP/AVP 9 a=rtpmap:9 G722/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Now the call is going on with transcoding from G711 to G722. I see it both in the increase in CPU usage (FS is running on a tiny for-home-use MIPS router) and with "show detailed_calls" where it showed read_codec, write_codec, b_read_codec and b_write_codec as PCMA before Hold, and read_codec and write_codec G722 and b_read_codec and b_write_codec PCMA after Hold. It's probably not the smartest move for the phone to renegotiate codecs at this point. But I think FS should be able to deal with it (without simply falling back to transcoding). I've tried if putting "disable-transcoding" into the profiles changes anything, but it didn't. "renegotiate-codec-on-hold" and "renegotiate-codec-on-reinvite" are gone since FS 1.6.10 so I can't try those. I read something about "indicate_hold" which probably means that FS will send a reINVITE on the other leg, so I might try that. Does anyone have any other thoughts on this? Kind regards, Sebastian
On Fri, Dec 09, 2016 at 10:47:35PM +0100, Sebastian Kemper wrote: <snip>
It's probably not the smartest move for the phone to renegotiate codecs at this point. But I think FS should be able to deal with it (without simply falling back to transcoding). I've tried if putting "disable-transcoding" into the profiles changes anything, but it didn't. "renegotiate-codec-on-hold" and "renegotiate-codec-on-reinvite" are gone since FS 1.6.10 so I can't try those. I read something about "indicate_hold" which probably means that FS will send a reINVITE on the other leg, so I might try that.
I thought about it some more and came to the conclusion that for a B2BUA it does seem legit to accept the first codec in the reINVTIE's offer and use transcoding to make the bridge work. It's not what I would like to happen, but that's a different story :D I also found a posting from 2011 which mentions this behavior: http://lists.freeswitch.org/pipermail/freeswitch-users/2011-December/078228.... Anyway, "case closed". Regards, Sebastian
I opened a JIRA on a related note earlier this year, because when you have this call recorded, and it gets switched between G711 and G722, it messes up the recording. On Mon, 12 Dec 2016, 04:11 Sebastian Kemper, <sebastian_ml@gmx.net> wrote:
On Fri, Dec 09, 2016 at 10:47:35PM +0100, Sebastian Kemper wrote:
<snip>
It's probably not the smartest move for the phone to renegotiate codecs at this point. But I think FS should be able to deal with it (without simply falling back to transcoding). I've tried if putting "disable-transcoding" into the profiles changes anything, but it didn't. "renegotiate-codec-on-hold" and "renegotiate-codec-on-reinvite" are gone since FS 1.6.10 so I can't try those. I read something about "indicate_hold" which probably means that FS will send a reINVITE on the other leg, so I might try that.
I thought about it some more and came to the conclusion that for a B2BUA it does seem legit to accept the first codec in the reINVTIE's offer and use transcoding to make the bridge work. It's not what I would like to happen, but that's a different story :D
I also found a posting from 2011 which mentions this behavior:
http://lists.freeswitch.org/pipermail/freeswitch-users/2011-December/078228....
Anyway, "case closed".
Regards, Sebastian
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
you could try setting execute_on_answer variable to lock in the codec Make an extension in the same context "assuming default for this example" <extension name="lock_codec"> <condition field="destination_number" expression="^lock_codec$"> <action application="set" data="absolute_codec_string=${rtp_use_codec_name}"/> </condition> </extension> In your normal call processing extension add this condition before calling bridge: <action application="set" data="execute_on_answer=execute_extension lock_codec XML default"/> Then when the channel is answered it will execute the extension and set the absolute_codec_string to whatever codec was first negotiated, that should limit what it will choose on the re-invite. You can probably set it on both legs with "export" instead of set or by adding it also to the {} before bridge. Dialplan: sofia/internal/1007@192.168.168.35 Regex (PASS) [lock_codec] destination_number(lock_codec) =~ /^lock_codec$/ break=on-false Dialplan: sofia/internal/1007@192.168.168.35 Action set(absolute_codec_string=${rtp_use_codec_name}) 2016-12-14 00:51:19.722495 [NOTICE] switch_core_session.c:2966 Execute set(absolute_codec_string=${rtp_use_codec_name}) EXECUTE sofia/internal/1007@192.168.168.35 set(absolute_codec_string=PCMU) 2016-12-14 00:51:19.722495 [DEBUG] mod_dptools.c:1562 SET sofia/internal/ 1007@192.168.168.35 [absolute_codec_string]=[PCMU] On Mon, Dec 12, 2016 at 12:37 AM, Joshua Gigg <giggsey@gmail.com> wrote:
I opened a JIRA on a related note earlier this year, because when you have this call recorded, and it gets switched between G711 and G722, it messes up the recording.
On Mon, 12 Dec 2016, 04:11 Sebastian Kemper, <sebastian_ml@gmx.net> wrote:
On Fri, Dec 09, 2016 at 10:47:35PM +0100, Sebastian Kemper wrote:
<snip>
It's probably not the smartest move for the phone to renegotiate codecs at this point. But I think FS should be able to deal with it (without simply falling back to transcoding). I've tried if putting "disable-transcoding" into the profiles changes anything, but it didn't. "renegotiate-codec-on-hold" and "renegotiate-codec-on-reinvite" are gone since FS 1.6.10 so I can't try those. I read something about "indicate_hold" which probably means that FS will send a reINVITE on the other leg, so I might try that.
I thought about it some more and came to the conclusion that for a B2BUA it does seem legit to accept the first codec in the reINVTIE's offer and use transcoding to make the bridge work. It's not what I would like to happen, but that's a different story :D
I also found a posting from 2011 which mentions this behavior: http://lists.freeswitch.org/pipermail/freeswitch-users/ 2011-December/078228.html
Anyway, "case closed".
Regards, Sebastian
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
On Wed, Dec 14, 2016 at 12:49:27AM -0600, Anthony Minessale wrote:
you could try setting execute_on_answer variable to lock in the codec
Make an extension in the same context "assuming default for this example"
<extension name="lock_codec">
<condition field="destination_number" expression="^lock_codec$"> <action application="set" data="absolute_codec_string=${rtp_use_codec_name}"/> </condition> </extension>
<snip> Hello Anthony, I tried it out and it worked. I added a new context with the lock_codec extension and then added the execute_on_answer in the context I was making test calls from. When using "set" the absolute_codec_string was set on A leg, when using "export" on both legs, like you said. Thanks! Sebastian
Documented on https://freeswitch.org/confluence/display/FREESWITCH/How+To%27s#HowTo's-Locknegotiatedcodec :) On Thu, Dec 15, 2016 at 7:36 PM, Sebastian Kemper <sebastian_ml@gmx.net> wrote:
On Wed, Dec 14, 2016 at 12:49:27AM -0600, Anthony Minessale wrote:
you could try setting execute_on_answer variable to lock in the codec
Make an extension in the same context "assuming default for this example"
<extension name="lock_codec">
<condition field="destination_number" expression="^lock_codec$"> <action application="set" data="absolute_codec_string=${rtp_use_codec_name}"/> </condition> </extension>
<snip>
Hello Anthony,
I tried it out and it worked. I added a new context with the lock_codec extension and then added the execute_on_answer in the context I was making test calls from.
When using "set" the absolute_codec_string was set on A leg, when using "export" on both legs, like you said.
Thanks! Sebastian
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ítalo Rossi italo@freeswitch.org
participants (4)
-
Anthony Minessale
-
Joshua Gigg
-
Sebastian Kemper
-
Ítalo Rossi