Open tanish20j opened 7 months ago
I want to share an update on the issue I was facing with a specific telecom provider. The issue was caused by the SDP from the gateway, which had the following format `
v=0 o=LucentIBCF 50839308 50839309 IN IP4 imsgroup0-328-0000008.kkp33.ims.mnc045.mcc404.3gppnetwork.org s=- c=IN IP4 10.2.13.242 t=0 0 a=recvonly m=audio 29518 RTP/AVP 0 101 c=IN IP4 10.2.13.242 b=RR:3000 b=RS:1000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=maxptime:40
`
As you can see, there is only a Session Attribute (a)
but no Media Attribute (a)
for the media direction. This made thesdp_session()
function create sdp->sdp_attributes->a_name
and sdp->sdp_media->m_mode
with the value recvonly
in src/switch_core_media.c
I temporarily fixed this issue by adding a check in the for (attr = sdp->sdp_attributes; attr; attr = attr->a_next) {
to skip else if (!strcasecmp(attr->a_name, <flow direction>) && m->m_mode != <flow direction>)
Is this the correct behavior of the sdp_session() function? Should I submit a pull request for this fix or should I report this issue to sofia-sip instead?
I checked test_sdp in sofia-sip, it is working as expected. I think FS is not handling SDP properly when it has Session Attribute (a)
instead of Media Attribute (a)
Describe the bug Cannot hear any sound on leg-A after I unhold it using uuid_hold. Can hear sound on leg-B. [ sending INVITE sdp(recvonly) instead of INVITE sdp(sendrecv) ] . Call fixed when:
To Reproduce Steps to reproduce the behavior:
Expected behavior should send sip INVITE sdp(sendrecv) when unholding
Package version or git hash
Trace logs