FreeSWITCH does not do hold for the re-INVITE

FreeSWITCH
1

SIP Phone send re-INVITE with SDP as below a=sendonly , but FreeSWITCH does not process HOLD media channel

v=0
o=mozilla...THIS_IS_SDPARTA-99.0 1083816313373495733 2 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 48:05:B3:A1:9B:EE:CE:57:A6:E6:91:BD:BE:AB:D1:EB:84:F5:E6:BB:AD:A0:4B:93:25:4C:5D:28:DD:41:5E:98
a=ice-options:trickle
a=msid-semantic: WMS *
a=group:BUNDLE 0
m=audio 49360 UDP/TLS/RTP/SAVPF 109 101 9 0 8
c=IN IP4 80.235.78.122
a=rtpmap:109 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=setup:actpass
a=mid:0
a=msid:{5dc3b303-1242-4358-a27c-ea3990b8e05c} {fefa2c10-bd7e-446b-bcf1-0e7c88f8bcfd}
a=sendonly
a=ice-ufrag:d6559f70
a=ice-pwd:4965710760d61a77906f1e15b493de8c
a=candidate:0 1 UDP 2122252543 10.10.10.89 49360 typ host
a=candidate:2 1 TCP 2105524479 10.10.10.89 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 80.235.78.122 49360 typ srflx raddr 10.10.10.89 rport 49360
a=end-of-candidates
a=ssrc:1638860689 cname:{9105066b-6e7f-4659-9cac-846c716ab74f}
a=rtcp-mux
2

We’re gonna need more info, are you talking about not sending the hold to the other leg?

3

freeswitch was confuse on session vs media attribute level a=sendrecv and a=sendonly
where media attribute level should overwrite session attribute level but freeswitch simply ignore it,

4

Doubtful FS was confused. Please provide a complete pcap, or a sipp scenario that replicates this.

/b