[asterisk-bugs] [JIRA] (ASTERISK-24122) res_pjsip mangles SAVPF invite if use_avpf=no

Fri Oct 10 09:55:30 CDT 2014

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222984#comment-222984 ] 

Matt Jordan commented on ASTERISK-24122:
----------------------------------------

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}

> res_pjsip mangles SAVPF invite if use_avpf=no
> ---------------------------------------------
>
>                 Key: ASTERISK-24122
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24122
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 12.4.0
>            Reporter: James Van Vleet
>            Assignee: Rusty Newton
>            Severity: Minor
>
> 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)

--
This message was sent by Atlassian JIRA
(v6.2#6252)