search

signalwire / freeswitch

FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a versatile software implementation that runs on any commodity hardware. From a Raspberry PI to a multi-core server, FreeSWITCH can unlock the telecommunications potential of any device.
https://freeswitch.com/#getting-started
Other
3.51k stars 1.4k forks source link

FreeSWITCH does not hold/unhold #2225

Open Jakihiko opened 1 year ago

Jakihiko commented 1 year ago

Describe the bug FreeSWITCH does not do hold for the re-INVITE

Client 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
silviucpp commented 11 months ago

I have same problem with webrtc as well via sipjs. I think the problem is related to :

The first "a=sendrecv" appears at the session-level of the SDP and the second "a=sendonly" is at the media-level.

Still not clear yet if this is the problem but looking fast to the FS code the session-level overrides the media one.

silviucpp commented 11 months ago

I did more research, and my results are here:

The problem is only on Firefox webrtc. Firefox seems to add in sdp at session-level a=sendrecv and then for the connection itself you can find the proper direction value as sendonly.

Looking here: https://github.com/onsip/SIP.js/issues/840#issuecomment-673546782 this seems to be valid from a RFC point of view but freeswitch is overriding the connection direction with the one from session-level (which seems wrong behavior).

Chrome is not adding any direction at the session-level. Only on the connection level and works fine