[Home]

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:45Date Closed:2014-10-17 08:40:07
Priority:MinorRegression?
Status:Closed/CompleteComponents: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}