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