SIP Resource Discovery string is mostly hardcoded

[michaelplevy]

I enabled sip-message-dump.
The responses I see to SIP OPTIONS request did not match the configuration of my services. In my case, I am only running ASR and No TTS, but the SDP response to the Options requests shows:

m=application 0 TCP/MRCPv2 1
a=resource:speechsynth
a=resource:speechrecog
m=audio 0 RTP/AVP 0 8 96 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 L16/8000
a=rtpmap:101 telephone-event/8000

In the code in mrcp_sdp.c I see the the function sdp_resource_discovery_string_generate(). It has a mostly hardcoded response that includes both speechsynth and speechrecog.

offset += snprintf(buffer+offset,size-offset,
			"v=0\r\n"
			"o=%s 0 0 IN IP4 %s\r\n"
			"s=-\r\n"
			"c=IN IP4 %s\r\n"
			"t=0 0\r\n"
			"m=application 0 TCP/MRCPv2 1\r\n"
			"a=resource:speechsynth\r\n"
			"a=resource:speechrecog\r\n"
			"m=audio 0 RTP/AVP 0 8 96 101\r\n"
			"a=rtpmap:0 PCMU/8000\r\n"
			"a=rtpmap:8 PCMA/8000\r\n"
			"a=rtpmap:96 L16/8000\r\n"
			"a=rtpmap:101 telephone-event/8000\r\n",
			origin,
			ip,
			ip);

The similar method used for invite sdp_control_media_generate() seems to dynamically determine the resource to include in the response.

This is not causing a problem, but it does seem incorrect.

[achaloyan]

This is not causing a problem, but it does seem incorrect.

That is right. I logged such an issue many years ago to be addressed later. However, there has not been any compelling reasons so far.

In order to properly address the issue, a resource discovery request needs to be propagated through the stack and a corresponding response be composed asynchronously thereafter, which should not be very hard to achieve, on the other side, is neither a very trivial task.

Duplicate of #61