Unsupported values in SPD

Hi,
I get the following messages in asterisk debug when sending Invite between peers:

[2012-07-31 06:14:12.667734] DEBUG[3741] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED.
[2012-07-31 06:14:12.667746] DEBUG[3741] chan_sip.c: Processing session-level SDP o=- 3552714817 3552714817 IN IP4 62.219.142.171... UNSUPPORTED.
[2012-07-31 06:14:12.667751] DEBUG[3741] chan_sip.c: Processing session-level SDP s=pjmedia... UNSUPPORTED.
[2012-07-31 06:14:12.667821] DEBUG[3741] chan_sip.c: Processing session-level SDP c=IN IP4 62.219.142.171... OK.
[2012-07-31 06:14:12.667829] DEBUG[3741] chan_sip.c: Processing session-level SDP b=AS:84... UNSUPPORTED.
[2012-07-31 06:14:12.667834] DEBUG[3741] chan_sip.c: Processing session-level SDP t=0 0... UNSUPPORTED.

Why are basic SDP tags are unsupported ? Is there a configuration parameter?

Thanks,
Gadi

Please provide the complete SDP and a description of the problem you are experiencing.

Also please identify the version of Asterisk; my, admittedly old version, cannot output UNSUPPORTED in upper case.

Asterisk version is Asterisk 10.5.1
full invite message and parsing:

<--- SIP read from UDP:62.219.142.171:27419 --->
INVITE sip:201673@184.73.165.182:5060 SIP/2.0^M
Via: SIP/2.0/UDP 192.168.1.61:58940;branch=z9hG4bK494324542;rport^M
From: <sip:201435@184.73.165.182:5060>;tag=294883610^M
To: <sip:201673@184.73.165.182:5060>^M
Contact: <sip:201435@192.168.1.61:58940;transport=udp>;+g.oma.sip-im;language="en,fr";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"^M
Call-ID: 9afccaba-cbd0-2156-affe-33d4bcea8774^M
CSeq: 592370732 INVITE^M
Content-Type: application/sdp^M
Content-Length: 2173^M
Max-Forwards: 70^M
Authorization: Digest username="201435",realm="asterisk",nonce="34138f9e",uri="sip:201673@184.73.165.182:5060",response="f286a2b2c89d6598d2f5d8a3ec1c54a1",algorithm=MD5^M
Route: <sip:184.73.165.182:5060;lr;transport=udp>^M
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"^M
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel^M
Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK, UPDATE, REFER^M
Privacy: none^M
P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000^M
User-Agent: IM-client/OMA1.0 ios-ngn-stack/v00 (doubango r000)^M
Supported: 100rel^M
^M
v=0^M
o=doubango 1983 678901 IN IP4 192.168.1.61^M
s=-^M
c=IN IP4 192.168.1.61^M
t=0 0^M
m=audio 12540 RTP/AVP 8 0 101^M
c=IN IP4 192.168.1.61^M
a=ptime:20^M
a=rtpmap:8 PCMA/8000/1^M
a=rtpmap:0 PCMU/8000/1^M
a=rtpmap:101 telephone-event/8000/1^M
a=fmtp:101 0-15^M
a=tcap:1 RTP/AVPF^M
a=pcfg:1 t=1^M
a=sendrecv^M
a=rtcp-mux^M
a=ssrc:2328743494 cname:ldjWoB60jbyQlR6e^M
a=ssrc:2328743494 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2^M
a=ssrc:2328743494 label:Doubango^M
a=ice-ufrag:BXagFunEZAnrsM6^M
a=ice-pwd:ICc7880ir071kMSZ0DVB5^M
a=mid:audio^M
a=candidate:rhJ7PBXD 1 UDP 2130706431 192.168.1.61 12540 typ host^M
a=candidate:rhJ7PBXD 2 UDP 2130706430 192.168.1.61 12541 typ host^M
a=candidate:9LWc7wnP 1 UDP 2130706175 10.152.113.148 8092 typ host^M
a=candidate:9LWc7wnP 2 UDP 2130706174 10.152.113.148 8093 typ host^M
a=candidate:srflxrhJ 1 UDP 1694498815 62.219.142.171 33722 typ srflx^M
a=candidate:srflxrhJ 2 UDP 1694498814 62.219.142.171 9290 typ srflx^M
m=video 37094 RTP/AVP 104 125 121 103^M
c=IN IP4 192.168.1.61^M
a=rtpmap:104 H264/90000^M
a=imageattr:104 recv [x=[128:16:352],y=[96:16:288]] send [x=[128:16:352],y=[96:16:288]]^M
a=fmtp:104 profile-level-id=42000d; packetization-mode=1^M
a=rtpmap:125 VP8/90000^M
a=imageattr:125 recv [x=[128:16:352],y=[96:16:288]] send [x=[128:16:352],y=[96:16:288]]^M
a=rtpmap:121 MP4V-ES/90000^M
a=imageattr:121 recv [x=[128:16:352],y=[96:16:288]] send [x=[128:16:352],y=[96:16:288]]^M
a=fmtp:121 profile-level-id=3^M
a=rtpmap:103 H263-1998/90000^M
a=fmtp:103 CIF=2;QCIF=2;SQCIF=2^M
a=tcap:1 RTP/AVPF^M
a=pcfg:1 t=1^M
a=sendrecv^M
a=rtcp-mux^M
a=ssrc:3741553754 cname:ldjWoB60jbyQlR6e^M
a=ssrc:3741553754 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2^M
a=ssrc:3741553754 label:Doubango^M
a=ice-ufrag:2lxIetzfkPikt3l^M
a=ice-pwd:78LNitYZWa5T3zF1DiBBM^M
a=mid:video^M
a=candidate:rUP0OvBW 1 UDP 2130706431 192.168.1.61 37094 typ host^M
a=candidate:rUP0OvBW 2 UDP 2130706430 192.168.1.61 37095 typ host^M
a=candidate:fnlhBXhp 1 UDP 2130706175 10.152.113.148 7952 typ host^M
a=candidate:fnlhBXhp 2 UDP 2130706174 10.152.113.148 7953 typ host^M
a=candidate:srflxrUP 1 UDP 1694498815 62.219.142.171 20639 typ srflx^M
a=candidate:srflxrUP 2 UDP 1694498814 62.219.142.171 25820 typ srflx^M

<------------->
[2012-07-31 06:56:56.271141] VERBOSE[3844] chan_sip.c: --- (19 headers 56 lines) ---
[2012-07-31 06:56:56.271230] VERBOSE[3844] chan_sip.c: Sending to 62.219.142.171:27419 (NAT)
[2012-07-31 06:56:56.271238] DEBUG[3844] chan_sip.c: Initializing initreq for method INVITE - callid 9afccaba-cbd0-2156-affe-33d4bcea8774
[2012-07-31 06:56:56.271244] VERBOSE[3844] chan_sip.c: Using INVITE request as basis request - 9afccaba-cbd0-2156-affe-33d4bcea8774
[2012-07-31 06:56:56.274933] DEBUG[3844] res_config_mysql.c: MySQL RealTime: Connection okay.
[2012-07-31 06:56:56.274955] DEBUG[3844] res_config_mysql.c: MySQL RealTime: Retrieve SQL: SELECT * FROM sip_buddies WHERE name = '201435' AND host = 'dynamic'
[2012-07-31 06:56:56.277147] VERBOSE[3844] chan_sip.c: Found peer '201435' for '201435' from 62.219.142.171:27419
[2012-07-31 06:56:56.277221] DEBUG[3844] rtp_engine.c: Using engine 'asterisk' for RTP instance '0xa146350'
[2012-07-31 06:56:56.277270] DEBUG[3844] res_rtp_asterisk.c: Allocated port 26132 for RTP instance '0xa146350'
[2012-07-31 06:56:56.277277] DEBUG[3844] rtp_engine.c: RTP instance '0xa146350' is setup and ready to go
[2012-07-31 06:56:56.277291] DEBUG[3844] rtp_engine.c: Using engine 'asterisk' for RTP instance '0xa0d6d38'
[2012-07-31 06:56:56.277323] DEBUG[3844] res_rtp_asterisk.c: Allocated port 18834 for RTP instance '0xa0d6d38'
[2012-07-31 06:56:56.277328] DEBUG[3844] rtp_engine.c: RTP instance '0xa0d6d38' is setup and ready to go
[2012-07-31 06:56:56.277343] DEBUG[3844] res_rtp_asterisk.c: Setup RTCP on RTP instance '0xa0d6d38'
[2012-07-31 06:56:56.277356] DEBUG[3844] rtp_engine.c: Using engine 'asterisk' for RTP instance '0xa1f71b8'
[2012-07-31 06:56:56.277395] DEBUG[3844] res_rtp_asterisk.c: Allocated port 26778 for RTP instance '0xa1f71b8'
[2012-07-31 06:56:56.277400] DEBUG[3844] rtp_engine.c: RTP instance '0xa1f71b8' is setup and ready to go
[2012-07-31 06:56:56.277414] DEBUG[3844] res_rtp_asterisk.c: Setup RTCP on RTP instance '0xa1f71b8'
[2012-07-31 06:56:56.277428] DEBUG[3844] res_rtp_asterisk.c: Setup RTCP on RTP instance '0xa146350'
[2012-07-31 06:56:56.277438] DEBUG[3844] chan_sip.c: Setting NAT on RTP to On
[2012-07-31 06:56:56.277443] DEBUG[3844] chan_sip.c: Setting NAT on VRTP to On
[2012-07-31 06:56:56.277447] DEBUG[3844] chan_sip.c: Setting NAT on TRTP to On
[2012-07-31 06:56:56.277534] DEBUG[3844] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED.
[2012-07-31 06:56:56.277544] DEBUG[3844] chan_sip.c: Processing session-level SDP o=doubango 1983 678901 IN IP4 192.168.1.61... UNSUPPORTED.
[2012-07-31 06:56:56.277549] DEBUG[3844] chan_sip.c: Processing session-level SDP s=-... UNSUPPORTED.
[2012-07-31 06:56:56.277604] DEBUG[3844] chan_sip.c: Processing session-level SDP c=IN IP4 192.168.1.61... OK.
[2012-07-31 06:56:56.277612] DEBUG[3844] chan_sip.c: Processing session-level SDP t=0 0... UNSUPPORTED.
[2012-07-31 06:56:56.277622] VERBOSE[3844] chan_sip.c: Found RTP audio format 8
[2012-07-31 06:56:56.277627] DEBUG[3844] rtp_engine.c: Setting payload 8 based on m type on 0xb51a15b0
[2012-07-31 06:56:56.277634] VERBOSE[3844] chan_sip.c: Found RTP audio format 0
[2012-07-31 06:56:56.277639] DEBUG[3844] rtp_engine.c: Setting payload 0 based on m type on 0xb51a15b0
[2012-07-31 06:56:56.277645] VERBOSE[3844] chan_sip.c: Found RTP audio format 101
[2012-07-31 06:56:56.277650] DEBUG[3844] rtp_engine.c: Setting payload 101 based on m type on 0xb51a15b0
[2012-07-31 06:56:56.277697] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP c=IN IP4 192.168.1.61... OK.
[2012-07-31 06:56:56.277707] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=ptime:20... OK.
[2012-07-31 06:56:56.277717] VERBOSE[3844] chan_sip.c: Found audio description format PCMA for ID 8
[2012-07-31 06:56:56.277722] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:8 PCMA/8000/1... OK.
[2012-07-31 06:56:56.277730] VERBOSE[3844] chan_sip.c: Found audio description format PCMU for ID 0
[2012-07-31 06:56:56.277734] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:0 PCMU/8000/1... OK.
[2012-07-31 06:56:56.277742] VERBOSE[3844] chan_sip.c: Found audio description format telephone-event for ID 101
[2012-07-31 06:56:56.277747] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:101 telephone-event/8000/1... OK.
[2012-07-31 06:56:56.277753] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=fmtp:101 0-15... UNSUPPORTED.
[2012-07-31 06:56:56.277758] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=tcap:1 RTP/AVPF... UNSUPPORTED.
[2012-07-31 06:56:56.277764] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=pcfg:1 t=1... UNSUPPORTED.
[2012-07-31 06:56:56.277769] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=sendrecv... OK.
[2012-07-31 06:56:56.277774] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=rtcp-mux... UNSUPPORTED.
[2012-07-31 06:56:56.277779] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=ssrc:2328743494 cname:ldjWoB60jbyQlR6e... UNSUPPORTED.
[2012-07-31 06:56:56.277785] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=ssrc:2328743494 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2... UNSUPPORTED.
[2012-07-31 06:56:56.277790] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=ssrc:2328743494 label:Doubango... UNSUPPORTED.
[2012-07-31 06:56:56.277796] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=ice-ufrag:BXagFunEZAnrsM6... UNSUPPORTED.
[2012-07-31 06:56:56.277801] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=ice-pwd:ICc7880ir071kMSZ0DVB5... UNSUPPORTED.
[2012-07-31 06:56:56.277806] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=mid:audio... UNSUPPORTED.
[2012-07-31 06:56:56.277812] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=candidate:rhJ7PBXD 1 UDP 2130706431 192.168.1.61 12540 typ host... UNSUPPORTED.
[2012-07-31 06:56:56.277817] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=candidate:rhJ7PBXD 2 UDP 2130706430 192.168.1.61 12541 typ host... UNSUPPORTED.
[2012-07-31 06:56:56.277822] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=candidate:9LWc7wnP 1 UDP 2130706175 10.152.113.148 8092 typ host... UNSUPPORTED.
[2012-07-31 06:56:56.277828] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=candidate:9LWc7wnP 2 UDP 2130706174 10.152.113.148 8093 typ host... UNSUPPORTED.
[2012-07-31 06:56:56.277833] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=candidate:srflxrhJ 1 UDP 1694498815 62.219.142.171 33722 typ srflx... UNSUPPORTED.
[2012-07-31 06:56:56.277838] DEBUG[3844] chan_sip.c: Processing media-level (audio) SDP a=candidate:srflxrhJ 2 UDP 1694498814 62.219.142.171 9290 typ srflx... UNSUPPORTED.
[2012-07-31 06:56:56.277847] VERBOSE[3844] chan_sip.c: Found RTP video format 104
[2012-07-31 06:56:56.277851] DEBUG[3844] rtp_engine.c: Setting payload 104 based on m type on 0xb5196270
[2012-07-31 06:56:56.277858] VERBOSE[3844] chan_sip.c: Found RTP video format 125
[2012-07-31 06:56:56.277864] VERBOSE[3844] chan_sip.c: Found RTP video format 121
[2012-07-31 06:56:56.277868] DEBUG[3844] rtp_engine.c: Setting payload 121 based on m type on 0xb5196270
[2012-07-31 06:56:56.277874] VERBOSE[3844] chan_sip.c: Found RTP video format 103
[2012-07-31 06:56:56.277879] DEBUG[3844] rtp_engine.c: Setting payload 103 based on m type on 0xb5196270
[2012-07-31 06:56:56.277924] DEBUG[3844] chan_sip.c: Processing media-level (video) SDP c=IN IP4 192.168.1.61... OK.

My problem is the session-level descriptions are unsupported.

Thanks,
Gadi

Are the ^M’s an artifact of how you have captured this for here?

Is there any possibility that there is something invisible, like a UTF-8 byte order mark at the start of each line?

Other than that, I can’t see anything that would cause things to be rejected in earlier versions of Asterisk, so I’d be surprised if it were rejected in the latest, although it is more usual to have an m= line.

I have some more insights and a questions.
From the code in chan_sip.c I see that the support in session-level SDP is only for a, o and c.

/* Scan session level SDP parameters (lines before first media stream) */
	while ((type = get_sdp_line(&iterator, next - 1, req, &value)) != '\0') {
		int processed = FALSE;
		switch (type) {
		case 'o':
			/* If we end up receiving SDP that doesn't actually modify the session we don't want to treat this as a fatal
			 * error. We just want to ignore the SDP and let the rest of the packet be handled as normal.
			 */
			if (!process_sdp_o(value, p)) {
				res = (p->session_modify == FALSE) ? 0 : -1;
				goto process_sdp_cleanup;
			}
			break;
		case 'c':
			if (process_sdp_c(value, &sessionsa)) {
				processed = TRUE;
				sa = &sessionsa;
				vsa = sa;
				tsa = sa;
				isa = sa;
			}
			break;
		case 'a':
			if (process_sdp_a_sendonly(value, &sendonly)) {
				processed = TRUE;
				vsendonly = sendonly;
			}
			else if (process_sdp_a_audio(value, p, &newaudiortp, &last_rtpmap_codec))
				processed = TRUE;
			else if (process_sdp_a_video(value, p, &newvideortp, &last_rtpmap_codec))
				processed = TRUE;
			else if (process_sdp_a_text(value, p, &newtextrtp, red_fmtp, &red_num_gen, red_data_pt, &last_rtpmap_codec))
				processed = TRUE;
			else if (process_sdp_a_image(value, p))
				processed = TRUE;
			break;
		}

		ast_debug(3, "Processing session-level SDP %c=%s... %s\n", type, value, (processed == TRUE)? "OK." : "UNSUPPORTED.");
	}

so no other tags are supported. So my question is, do you know if there are extensions that can extend asterisk to support all session-level SDP tags?

Thanks,
Gadi

Looks to me that that version doesn’t like session level SDP at all, but tolerates some more than others.

I think the older versions didn’t fully parse SDP with multiple media, but this looks like a complete re-write at some stage.

There is one thing I wonder. There is a reference to changing the session. Are you sure that this code is in the first time parsing. I could imagine they could just have split out some of the re-invite processing.

Apart from going back to an older version, I can’t imagine there is any publically available code that does deal with session level SDP. I presume devices that omit m= lines are also rare.

You would need to read the change history and upgrade documents carefully, to see if this is intended behaviour. You can use svn blame to work out when the change was made, to find the specific revision log entry for the change.

Thank you. I will further investigate in SVN.