Failed to set remote answer sdp: Called with SDP without ice-ufrag and ice-pwd

Asterisk Asterisk WebRTC
1

I’m pretty sure some people are rolling their eyes on seeing this post… but i just cant seem to come right here. I have now read loads of articles dating back 3 or 4 years with the same issue - so it makes it difficult to debug since all the articles are so old.

Scenario:

  • I’m NOT repeat, NOT using WebRTC over the general Internet at all - this is 100% LAN based, in fact internet may be disabled in some cases.
  • I’m trying to use SipJS. (have tried 0.8X 0.11.X and 0.12.X)
  • I’m using Asterisk 13 (tried 13.21-certified and 13.24.1)
  • I’m NOT using PJSIP (im unlikely to change this)
  • I have uuid / uuid-dev installed
  • I have stunaddr:19302=stun.l.google.com set in rtp.conf

No matter what, I still get the same result

Setup:
[Browser User A] <= {LOCAL LAN} => https://[Asterisk]:443/ws <= {LOCAL LAN} => [Browser User A]

What’s working:

  • WebRTC: WSS, Register, Chat, Subscribe/Presence
  • SIP: Everything: TLS/TCP/UDP, Register, Audio calls, Video calls, Chat, Subscribe/Presence

Problem:

  • When establishing a call, SipJS / GoogleChrome errors with:

DOMException: Failed to execute ‘setRemoteDescription’ on ‘RTCPeerConnection’: Failed to set remote answer sdp: Called with SDP without ice-ufrag and ice-pwd.

  • If i take a look at the reply SDP, its clear it doesn’t:
SIP/2.0 200 OK
Via: SIP/2.0/WSS 6fh6cl3ics0h.invalid;branch=z9hG4bK4550538;received=192.168.88.88
From: "User A" <sip:webrtc@192.168.88.98>;tag=2vaifpjnv4
To: <sip:*1@192.168.88.98>;tag=as1b451b6a
Call-ID: gni6fkcsdefl0ibeqc9r
CSeq: 277 INVITE
Server: Asterisk BPX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:*1@192.168.88.98:5060;transport=ws>
Content-Type: application/sdp
Content-Length: 723

v=0
o=root 1408129947 1408129947 IN IP4 192.168.88.98
s=Asterisk PBX 13.24.1
c=IN IP4 192.168.88.98
b=CT:5000
t=0 0
m=audio 16684 RTP/SAVPF 111 0 8 126
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=maxptime:60
a=connection:new
a=setup:active
a=fingerprint:SHA-256 01:AF:2E:AD:BD:53:20:3C:BC:EF:3A:E6:A0:CB:8A:90:CC:E6:38:1F:2D:51:35:3C:76:42:C3:5F:11:64:4E:C9
a=rtcp-mux
a=sendrecv
m=video 15838 RTP/SAVPF 96
a=connection:new
a=setup:active
a=fingerprint:SHA-256 01:AF:2E:AD:BD:53:20:3C:BC:EF:3A:E6:A0:CB:8A:90:CC:E6:38:1F:2D:51:35:3C:76:42:C3:5F:11:64:4E:C9
a=rtpmap:96 VP8/90000
a=rtcp-fb:* ccm fir
a=rtcp-mux
a=sendrecv
  • You can see that the origional INVITE had the ICE candidates (and yes it offered the wrong/live IP)
INVITE sip:*1@192.168.88.98 SIP/2.0
Via: SIP/2.0/WSS 6fh6cl3ics0h.invalid;branch=z9hG4bK82330
Max-Forwards: 70
To: <sip:*1@192.168.88.98>
From: "User A" <sip:webrtc@192.168.88.98>;tag=2vaifpjnv4
Call-ID: gni6fkcsdefl0ibeqc9r
CSeq: 276 INVITE
Contact: <sip:svv74auo@6fh6cl3ics0h.invalid;transport=wss;ob>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: SIPjs via WebRTC
Content-Type: application/sdp
Content-Length: 6318

v=0
o=- 4588150804381803861 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS z5p3sME8D09gDGuCL3PrqBgYBuJ3K2cEXCD1
m=audio 51124 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 155.93.188.227
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:2946509287 1 udp 2122260223 192.168.88.88 51124 typ host generation 0 network-id 2
a=candidate:4156766641 1 udp 2122194687 192.168.88.87 63032 typ host generation 0 network-id 1 network-cost 10
a=candidate:3777221911 1 tcp 1518280447 192.168.88.88 9 typ host tcptype active generation 0 network-id 2
a=candidate:3108029761 1 tcp 1518214911 192.168.88.87 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:786968403 1 udp 1686052607 155.93.188.227 51124 typ srflx raddr 192.168.88.88 rport 51124 generation 0 network-id 2
a=candidate:1988837125 1 udp 1685987071 155.93.188.227 63032 typ srflx raddr 192.168.88.87 rport 63032 generation 0 network-id 1 network-cost 10
a=ice-ufrag:6fX6
a=ice-pwd:ETNNNbDhRknxadu52C3ozD++
a=ice-options:trickle
a=fingerprint:sha-256 73:DF:11:8C:3B:87:1B:9E:FB:68:31:64:43:AF:2E:8A:2B:1D:38:9E:4A:99:3A:CD:E6:B9:87:EF:19:DB:B3:C3
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
.............
More codec descriptors here...
  • If I debug the INVITE, it clearly ready the ICE information but says it unsupported or fail:
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=candidate:2946509287 1 udp 2122260223 192.168.88.88 51124 typ host generation 0 network-id 2... UNSUPPORTED OR FAILED.
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=candidate:4156766641 1 udp 2122194687 192.168.88.87 63032 typ host generation 0 network-id 1 network-cost 10... UNSUPPORTED OR FAILED.
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=candidate:3777221911 1 tcp 1518280447 192.168.88.88 9 typ host tcptype active generation 0 network-id 2... UNSUPPORTED OR FAILED.
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=candidate:3108029761 1 tcp 1518214911 192.168.88.87 9 typ host tcptype active generation 0 network-id 1 network-cost 10... UNSUPPORTED OR FAILED.
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=candidate:786968403 1 udp 1686052607 155.93.188.227 51124 typ srflx raddr 192.168.88.88 rport 51124 generation 0 network-id 2... UNSUPPORTED OR FAILED.
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=candidate:1988837125 1 udp 1685987071 155.93.188.227 63032 typ srflx raddr 192.168.88.87 rport 63032 generation 0 network-id 1 network-cost 10... UNSUPPORTED OR FAILED.
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=ice-ufrag:6fX6... UNSUPPORTED OR FAILED.
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=ice-pwd:ETNNNbDhRknxadu52C3ozD++... UNSUPPORTED OR FAILED.
chan_sip.c:10799 process_sdp: Processing media-level (audio) SDP a=ice-options:trickle... UNSUPPORTED OR FAILED.

Any Ideas??

Closing thoughts… A few years ago, i had a working solution (not sure of the versions etc) and don’t remember it being so difficult. I’m not sure if this is a SIPJS issue or an Asterisk issue. If SIPJS offered the correct (local) IP address, then media would work, and it should not close the call. (SIPJS is sending a BYE in reaction to the failed SDP). Then again… why wouldn’t Asterisk just respond with the ice-ufrag and ice-pwd???

1 Like
2

Your configuration does not have ICE enabled, or your Asterisk was not built with PJPROJECT (if you have not built with bundled[1] then do so and it will automatically bring it in) and thus does not have ICE support. PJPROJECT is what provides the ICE/STUN/TURN support.

[1] https://blogs.asterisk.org/2016/03/16/asterisk-13-8-0-now-easier-pjsip-install-method/

1 Like
3

You are correct, that i have not included PJPROJECT, Ill give that a try.

Question: Do I need to include the PJSIP modules in the “make menuselct”? I really would rather not… I not going to change 1000’s of lines of dialplan and back-end code to accommodate PJ SIP, and since im unlikely to use it, can i leave them out of the build?

Sidebar: I’m sure PJ SIP is seaming like a silver bullet for you guys… but it a real pain from the developer side. Just putting it out there :slight_smile:

4

You don’t have to use PJSIP for SIP traffic. The res_pjproject module has to be built and loaded though as that contains the entire library, part of which the RTP stack uses for ICE/STUN/TURN.

I don’t know if I’d call it a “silver bullet” but the PJSIP support has a defined design, is extensible, is written to our modern standards, and is easier to debug and isolate. It has allowed us to write things that would not have been possible in chan_sip (such as multiparty video conferencing for WebRTC) without major work. Relying on a third party library also means that when we contribute fixes they then appear in other things - such as mobile softphones - thus helping things over all.

You are of course free to not use it but chan_sip may go away one day out of the tree.

5

Hmmmmm, ok, you have me interested now :open_mouth:

6

There is a blog post[1] talking about.

[1] https://blogs.asterisk.org/2017/09/20/asterisk-15-multi-stream-media-sfu/

7

I know we are going off topic here and i could just try… but im waiting for the build to finish compiling (slow computer)… anyway does the old “confbridge” application support video… because i have used it very successfully in the past for rather large scale (semi-enterprise) conferencing solutions - tho i only used it with normal SIP audio.

8

For normal devices it supports video switching[1], so you only get a single video feed. For the WebRTC SFU it supports multiple streams so you see multiple people.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Configuration_app_confbridge#Asterisk16Configuration_app_confbridge-bridge_profile_video_mode

9

Ok!! partial success :slight_smile:

The ICE information is sent back :), yay :

a=ice-ufrag:1b7ed5713d3c2d9b177979563810c8e7
a=ice-pwd:57a1b2067c8d5283770750e96ad3cec2
a=candidate:Hc0a85862 1 UDP 2130706431 192.168.88.98 18382 typ host
a=candidate:S9b5dbce3 1 UDP 1694498815 155.93.188.227 18382 typ srflx raddr 192.168.88.98 rport 18382
a=candidate:Hc0a85862 2 UDP 2130706430 192.168.88.98 18383 typ host
a=candidate:S9b5dbce3 2 UDP 1694498814 155.93.188.227 18383 typ srflx raddr 192.168.88.98 rport 18383

But… I get no audio :frowning:

SipJS invites with this (my ISP ADSL ipaddress):

c=IN IP4 155.93.188.227

But Asterisk reply is with this (my local LAN ip address):

c=IN IP4 192.168.88.98

What can i do here?

10

The c line is not used for WebRTC. The ICE candidates are used to find a flow that works. You would need to use “rtp set debug on” to see if ICE negotiated on the Asterisk side (it will say via ICE for outgoing traffic if successful), if it doesn’t you would need to dig into packet traces and the browser side (chrome://webrtc-internals) to see if it provides any insight.

Unfortunately when WebRTC doesn’t work it’s not a “oh just do this” to make it work. It’s built on a lot of technologies and the browser can be a black box on what it is doing.

The current browsers may have also broken non-bundle support (video and audio running over same RTP port) as that is not commonly used. PJSIP supports bundle, so it doesn’t behave as chan_sip in that regard.

11

Yea no i think something else is going on because I made a call to GroundWire on my cell phone and got full video and audio from my Browser to the phone, but nothing seemed to playback (from phone to browser) But i only seem to have a audio object there… so it may just be the setup of my HTML/JavaScript.

Anyway… ill push on, thanks for the help Joshua

12

Looks like it is the HTML JavaScript (192.168.88.88 is the PC ip address and packets area being sent and received).

...
Got  RTP packet from    192.168.88.88:62496 (type 96, seq 007967, ts 3217297455, len 000805)
Sent RTP packet to      192.168.88.88:52465 (via ICE) (type 111, seq 007800, ts 316080, len 000027)
Got  RTP packet from    192.168.88.88:62496 (type 96, seq 007968, ts 3217297455, len 000805)
Got  RTP packet from    192.168.88.88:52465 (type 111, seq 021118, ts 2678357426, len 000084)
Sent RTP packet to      192.168.88.88:52465 (via ICE) (type 111, seq 007801, ts 317040, len 000028)
Got  RTP packet from    192.168.88.88:52465 (type 111, seq 021119, ts 2678358386, len 000084)
...
13

Yes, seems as though traffic is flowing as expected.