Summary: | ASTERISK-24122: Documentaton for res_pjsip option use_avpf needs to be fixed | ||
Reporter: | James Van Vleet (jvanvleet) | Labels: | |
Date Opened: | 2014-07-25 11:52:45 | Date Closed: | 2014-10-17 08:40:07 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Documentation Resources/res_pjsip |
Versions: | 12.4.0 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Attachments: | ||
Description: | Originally testing 12.4.0-rc1. Also tested with 12 head (r419442). Both version of asterisk using pjproject commit 21b3576112c98556a9753e3048bac5ba5a84881a (newest at the time) from the asterisk fork on github.
Reference: http://svnview.digium.com/svn/asterisk?view=revision&revision=408502 It appears that use_avpf is broken assuming I understand the referenced commit above. Testing using SIPML5 generated SDP: {noformat} v=0 o=- 5208809120103833000 2 IN IP4 127.0.0.1 s=Doubango Telecom - chrome t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS 2VaiG8N52dPmzSpovitoTzRdJ5dfCosuriag m=audio 37070 UDP/TLS/RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 <SNIP> a=rtcp:37070 IN IP4 <SNIP> a=candidate:3424360271 1 udp 2122260223 <SNIP> 55001 typ host generation 0 a=candidate:3424360271 2 udp 2122260223 <SNIP> 55001 typ host generation 0 a=candidate:386226586 1 udp 2122194687 <SNIP> 37070 typ host generation 0 a=candidate:386226586 2 udp 2122194687 <SNIP> 37070 typ host generation 0 a=candidate:3683149321 1 udp 1685987071 <SNIP> 37070 typ srflx raddr 192.168.54.111 rport 37070 generation 0 a=candidate:3683149321 2 udp 1685987071 <SNIP> 37070 typ srflx raddr 192.168.54.111 rport 37070 generation 0 a=candidate:2191027135 1 tcp 1518280447 <SNIP> 0 typ host generation 0 a=candidate:2191027135 2 tcp 1518280447 <SNIP> 0 typ host generation 0 a=candidate:1501996394 1 tcp 1518214911 <SNIP> 0 typ host generation 0 a=candidate:1501996394 2 tcp 1518214911 <SNIP> 0 typ host generation 0 a=ice-ufrag:RjtUyTT8FJWTlMPf a=ice-pwd:x9hiS9/Il/ADx+Zr0lTClxsG a=ice-options:google-ice a=fingerprint:sha-256 69:D0:0C:C3:A5:4F:C3:50:56:8F:49:4D:E8:DF:06:E7:08:70:2A:32:BC:F7:2D:00:CA:B3:EE:14:54:52:9E:9F a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=sendrecv a=rtcp-mux a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:4041464331 cname:T0+0+J3abDTx6xmg a=ssrc:4041464331 msid:2VaiG8N52dPmzSpovitoTzRdJ5dfCosuriag babc4f16-bdfe-4081-bb35-e73eba8302ca a=ssrc:4041464331 mslabel:2VaiG8N52dPmzSpovitoTzRdJ5dfCosuriag a=ssrc:4041464331 label:babc4f16-bdfe-4081-bb35-e73eba8302ca {noformat} use_avpf=yes for the endpoint in question produces a good SDP response with negotiated ice information, media and the like. All is well. However with use_avpf=no the following odd thing is sent: {noformat} Content-Type: application/sdp Content-Length: 173 v=0 o=- 4008842760 4 IN IP4 <SNIP> s=Asterisk c=IN IP4 <SNIP> t=0 0 m=audio 0 UDP/TLS/RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 <SNIP> {noformat} <next log line here> For some reason all ICE and media information is missing from the response SDP. Notice the Content-Length shows the abbreviated SDP is at least intentional at that level. This does not happen with all call types - calls using blink to the same endpoint (no encryption if I recall) work fine however the the sipML5 phone is constantly broken. I don't think it matters but I should note that we are not using the asterisk web-socket interfaces at the moment - that is terminating on a different gateway and the sdp forwarded to asterisk. There is nothing different (interesting) in the debug log between use_avpf yes and no however I can attach if necessary. {noformat} [endpoint] type=endpoint context=default ; Default context for incoming calls allow=ulaw direct_media=no rtp_symmetric=yes media_address=54.187.64.133 use_avpf=yes ;# asterisk will accept avfp if this is false. this *requires* avpf ice_support=yes media_encryption=dtls dtls_cert_file=/etc/asterisk/certs/fakedomain.com.crt dtls_private_key=/etc/asterisk/certs/fakedomain.com.key {noformat} (with blink I also comment out media_encryption) | ||
Comments: | By: Joshua C. Colp (jcolp) 2014-07-25 11:57:55.164-0500 Unfortunately this is expected behavior and not something that can be changed without purposely breaking the PJMEDIA SDP negotiator (which would be a change for upstream). What is happening is that an SDP answer is being produced with a different transport, in this case using AVP. The offer and answer are negotiated together and as the transport differs the negotiation fails. Since the answer SDP must contain a media stream one is added without a port. By: Joshua C. Colp (jcolp) 2014-07-25 11:59:21.271-0500 Oh I understand what you mean. Nevermind, carry on! By: James Van Vleet (jvanvleet) 2014-07-25 12:00:17.602-0500 Thanks - but then should be http://svnview.digium.com/svn/asterisk?view=revision&revision=408502 should be altered? I guess that is what lead me astray... By: Rusty Newton (rnewton) 2014-08-01 17:05:27.171-0500 I should have asked for this earlier. Can you produce a complete pcap of the call to help us reproduce the issue? You should include an [Asterisk debug log|https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information] along with it. Both verbose and debug should be turned up to 5 or above. By: Rusty Newton (rnewton) 2014-08-20 15:05:53.916-0500 {quote} This does not happen with all call types - calls using blink to the same endpoint (no encryption if I recall) work fine however the the sipML5 phone is constantly broken. {quote} Additionally - can you include the requested debug and captures for both the working and non-working call scenarios: By: Matt Jordan (mjordan) 2014-10-10 09:53:42.508-0500 I think the documentation of this option - which I added/improved/got wrong - is ... wrong. [~file] and I discussed this a bit in {{#asterisk-dev}}, and I think we ended up on the following: * If an offer contains RTP/AVP or RTP/SAVP, * And if {{use_avpf=Yes}}, * Then Asterisk should reject the inbound INVITE request with a 488 The reason being, there's a very good chance that any outbound INVITE request we send to such an endpoint (which would contain RTP/AVPF or RTP/SAVPF) would fail, as the endpoint does not support RTP/AVPF|SAVPF. Even if it did, we'd be at the mercy of the endpoint understanding that it previously sent us RTP/AVP|SAVP, and now it's getting RTP/AVPF|SAVPF from us. {quote} (09:38:20 AM) file: yes (09:40:30 AM) mjordan: file: if use_avpf is set to True, and an inbound INVITE request contains an Offer with RTP/AVP, what should Asterisk do? (09:41:07 AM) file: reject it probably (09:41:11 AM) mjordan: heh (09:41:14 AM) mjordan: I enjoy the probably (09:41:58 AM) file: WELL (09:42:03 AM) file: there's two trains of thought... (09:42:21 AM) file: you can either match the incoming transport and it'll work, but any outgoing sessions will likely fail (09:42:30 AM) file: or you can reject it and fail incoming as well (09:43:14 AM) mjordan: well, it seems like use_avpf could mean "accept anything inbound, but offer AVPF on outbound" (09:43:26 AM) mjordan: where we simply echo in our SDP Answer whatever was offered (09:43:56 AM) file: there's an option to match transport (09:44:36 AM) mjordan: which option is that? (09:44:37 AM) file: media_use_received_transport (09:44:46 AM) mjordan: hm. (09:44:59 AM) mjordan: I guess it feels like use_avpf should only reflect outbound offers and should just leave inbound offers alone (09:45:30 AM) mjordan: with use_avpf probably trumping media_use_received_transport if use_avpf=yes (09:46:11 AM) file: there's pros and cons either way - the pro being inbound will just work, the con being if you don't know why... and do outbound... you'll be confused (09:48:09 AM) mjordan: well, let's say I have an endpoint that previously offered me AVP, which I accepted, and the call eventually hangs up. I then send an offer with AVPF. (09:48:44 AM) mjordan: That feels like either (a) it is up to the endpoint to accept both, just like Asterisk; or (b) the endpoint will reject it, and in that case, there's a misconfiguration: you don't want use_avpf to be set to yes for that endpoint, as we shouldn't be offering AVPF to it (09:49:19 AM) file: it'll reject it - but my point is that because there's magic behavior on inbound a person won't jump to that conclusion immediately (09:49:23 AM) file: cause it's half working (09:50:56 AM) mjordan: Hm. (09:51:09 AM) mjordan: Then I suppose what we should do is reject the offer with a 488. {quote} |