[Freeswitch-users] FS changes to transcoding after hold

Sat Dec 10 00:47:35 MSK 2016

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 at 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 at 172.31.255.129>;tag=3900142461
   To: <sip:500 at 172.31.255.129;user=phone>;tag=6SX155B96H1pp
   Call-ID: 1793314766 at 172_31_255_132
   CSeq: 4 INVITE
   Contact: <sip:301 at 172.31.255.132:5060>
   Proxy-Authorization: Digest username="301", realm="172.31.255.129", qop=auth, algorithm=MD5, uri="sip:500 at 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 at 172.31.255.129>;tag=3900142461
   To: <sip:500 at 172.31.255.129;user=phone>;tag=6SX155B96H1pp
   Call-ID: 1793314766 at 172_31_255_132
   CSeq: 4 INVITE
   Contact: <sip:500 at 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 at 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 at 172.31.255.129>;tag=3900142461
   To: <sip:500 at 172.31.255.129;user=phone>;tag=6SX155B96H1pp
   Call-ID: 1793314766 at 172_31_255_132
   CSeq: 5 INVITE
   Contact: <sip:301 at 172.31.255.132:5060>
   Proxy-Authorization: Digest username="301", realm="172.31.255.129", qop=auth, algorithm=MD5, uri="sip:500 at 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 at 172.31.255.129>;tag=3900142461
   To: <sip:500 at 172.31.255.129;user=phone>;tag=6SX155B96H1pp
   Call-ID: 1793314766 at 172_31_255_132
   CSeq: 5 INVITE
   Contact: <sip:500 at 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