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

Fri Jul 25 12:01:56 CDT 2014

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

James Van Vleet commented on ASTERISK-24122:
--------------------------------------------

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...

> 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
>            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:
> 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
> 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:
> 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>
> <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.
> [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  
> (with blink I also comment out media_encryption)

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