RTP IPv4/6 while SIP signaling over IPv4

Hi,

We currently have an Asterisk box behind an Opensips proxy that serves a large number of Websocket clients.
The link between Asterisk and Opensips is SIP over TCP (IPv4).

Some of our websocket clients only support IPv6. So when they send an INVITE to Opensips (and then Asterisk) with only IPv6 candidates, Asterisk does not include any IPv6 candidates in the OK reply. We have also observed that Asterisk only opens UDP ports for RTP on IPv4 - using the netstat command.

Our current theroy is that because the signaling happens over IPv4 then Asterisk assumes that the media (RTP) will be the same. (Source)

Is there any way we can get Asterisk to listen on both IPv4 and IPv6 for RTP even when the signaling is just over IPv4?

I’m happy to provide more details or an example call if that would be helpful!

Cheers,
Josh

PS
I think our situation is similar to this however we are using a proxy which means the signaling is always over IPv4

From an ICE candidate perspective, it should (and at least does for me and others) provide both IPv4 and IPv6 candidates. Are you referring to the normal c= line? In which case yes it would only do IPv4 to match the signaling.

What environment is this actually happening in? Distro and such.

Hi Joshua,

We are currently running Asterisk 18.8 in a Debian Stretch Docker container. The container is running in host network mode meaning it has access to the underlying network interfaces of the host.

Thanks for your quick reply! I have included as many details as I thought might be helpful for this please let me know if there is anything else that might be useful.

Kind Regards,
Josh

Here is the output of ip addr from inside the container (external IPv6 has some xxx’s). ens4 also has a public IPv4 address of 35.197.xx.xx that is not shown:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo            
       valid_lft forever preferred_lft forever                                                           
    inet6 ::1/128 scope host                                                                             
       valid_lft forever preferred_lft forever                                                           
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc mq state UP group default qlen 1000
    link/ether 42:01:0a:98:00:03 brd ff:ff:ff:ff:ff:ff
    inet 10.152.0.3/32 scope global dynamic ens4
       valid_lft 3593sec preferred_lft 3593sec                                                                                                                                                                     
    inet6 2600:1900:40b0:1xxx::/128 scope global                                                         
       valid_lft forever preferred_lft forever    
    inet6 fe80::4001:aff:fe98:3/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:3e:93:c6:b2 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:3eff:fe93:c6b2/64 scope link 
       valid_lft forever preferred_lft forever
4: br-e62f4842f2e4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:67:18:32:a9 brd ff:ff:ff:ff:ff:ff
    inet 172.21.0.1/16 brd 172.21.255.255 scope global br-e62f4842f2e4
       valid_lft forever preferred_lft forever
    inet6 fe80::42:67ff:fe18:32a9/64 scope link 
       valid_lft forever preferred_lft forever

Here is the transport/endpoint that we use in pjsip.conf

[transport]
type=transport
protocol=tcp
bind=0.0.0.0:6001

[webrtc_client]
type=endpoint
allow=!all,opus,ulaw,alaw,h264
aors=webrtc_client
context=webrtc-client
dtls_auto_generate_cert=yes
identify_by=header
max_audio_streams=16
max_video_streams=16
rtp_symmetric=yes
rtp_timeout=30
rtp_timeout_hold=30
transport=transport
webrtc=yes

Here is our rtp.conf

[general]
rtpstart=10000
rtpend=20000
rtpchecksums=yes
strictrtp=yes
icesupport=yes

[ice_host_candidates]
10.152.0.3 => 35.197.xx.xx

I have included an example call below which is an Invite to Asterisk.
You can see IPv6 candidates in the Invite (from client) but not the OK reponse (from Asterisk).

INVITE sip:+64XXXXXXXXXX@XXXXXX.XXXXX.vxt.co.nz SIP/2.0
Via: SIP/2.0/WSS qpk3qf7fgtvb.invalid;branch=z9hG4bK1345334
To: <sip:+64XXXXXXXX@XXXXXXX.vxt.co.nz>
From: <sip:webrtc_client@XXXXXXXX.vxt.co.nz>;tag=fasn1q6jp2
CSeq: 1 INVITE
Call-ID: 6483bsvdoii982q10oh4
Max-Forwards: 70
X-Vxt-User-Id: xxx
X-Vxt-User-Token: xxx
X-Vxt-Inbox-Id: +64xxx
X-Vxt-Call-Id: xxx
X-Vxt-Platform: web/0.0.0-latest
Contact: <sip:lglv9epn@qpk3qf7fgtvb.invalid;transport=ws;ob>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: SIP.js/0.20.0
Content-Type: application/sdp
Content-Length: 7006

v=0
o=- 2173660861984975638 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS 6174daa8-ca6f-4071-9c32-a797732d9a6b
m=audio 39447 UDP/TLS/RTP/SAVPF 111 63 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 10.129.0.2
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3655964491 1 udp 2122262783 2600:1900:40b0:fxxx:: 53169 typ host generation 0 network-id 2
a=candidate:3757563338 1 udp 2122194687 10.129.0.2 39447 typ host generation 0 network-id 1
a=candidate:2540334011 1 tcp 1518283007 2600:1900:40b0:fxxx:: 9 typ host tcptype active generation 0 network-id 2
a=candidate:2440307002 1 tcp 1518214911 10.129.0.2 9 typ host tcptype active generation 0 network-id 1
a=ice-ufrag:piH3
a=ice-pwd:tTFroFGwYSnu3NLBLjjC0rl1
a=ice-options:trickle
a=fingerprint:sha-256 0E:AB:D1:34:1D:1B:97:15:AF:4C:D4:97:DC:EA:57:11:6D:45:7F:8F:49:CA:AF:40:7D:C8:09:75:8C:52:94:20
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:6174daa8-ca6f-4071-9c32-a797732d9a6b 33042607-a62d-4c05-b56f-7397145fbb30
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
<< trimed rest >>
SIP/2.0 200 OK
Via: SIP/2.0/WSS qpk3qf7fgtvb.invalid;branch=z9hG4bK1345334
Call-ID: 6483bsvdoii982q10oh4
From: <sip:webrtc_client@XXXXXXX.vxt.co.nz>;tag=fasn1q6jp2
To: <sip:+64xxxxxxxxx@XXXXXXX.vxt.co.nz>;tag=0eac8795-f5fd-430e-b792-2cef5ead56cf
CSeq: 1 INVITE
Server: Asterisk PBX 18.8.0
Contact: <sip:XXXXXXX.vxt.co.nz:443;transport=ws;thinfo=xxx-->
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length:  1710

v=0
o=- 2496178966 4 IN IP4 10.152.0.3
s=Asterisk
c=IN IP4 10.152.0.3
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1
m=audio 19792 UDP/TLS/RTP/SAVPF 111 0 8 126
a=connection:new
a=setup:active
a=fingerprint:SHA-256 82:41:A2:55:6F:73:14:3F:B2:51:FA:AD:5E:D4:E6:07:19:3D:FD:F8:B5:47:C5:E4:50:41:10:E4:2E:50:1A:B7
a=ice-ufrag:262eab166296234810dcd82a7a5cfb44
a=ice-pwd:10b4d94f640ff90942cbcd31268048cc
a=candidate:H23c5be0e 1 UDP 2130706431 35.197.xx.xx 19792 typ host
a=candidate:Hac110001 1 UDP 2130706431 172.17.0.1 19792 typ host
a=candidate:Hac150001 1 UDP 2130706431 172.21.0.1 19792 typ host
a=candidate:Hac140001 1 UDP 2130706431 172.20.0.1 19792 typ host
a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux
a=ssrc:772228098 cname:d197734f-8f4f-49d6-a1f8-23720ecfda2a
a=msid:79a2696a-f418-4ea1-b5ec-2974435feb8d 4b230a75-c3fc-4013-ace5-bbb8251a0812
a=rtcp-fb:* transport-cc
a=mid:0
m=video 19792 UDP/TLS/RTP/SAVPF 102as access to the underlying network interfaces of the host.
a=connection:new
a=setup:active
a=fingerprint:SHA-256 82:41:A2:55:6F:73:14:3F:B2:51:FA:AD:5E:D4:E6:07:19:3D:FD:F8:B5:47:C5:E4:50:41:10:E4:2E:50:1A:B7
a=ice-ufrag:262eab166296234810dcd82a7a5cfb44
a=ice-pwd:10b4d94f640ff90942cbcd31268048cc
a=rtpmap:102 H264/90000
a=fmtp:102 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001F
a=sendonly
a=rtcp-mux
a=ssrc:966354175 cname:117942ca-b8eb-4eeb-ab95-d543805c0ba4
a=msid:53f60876-fe3e-43c3-9acc-be6b0cf620e6 d2e6cc76-894e-44fa-9e71-191b279bb7b8
a=rtcp-fb:* transport-cc
a=rtcp-fb:* ccm fir
a=rtcp-fb:* goog-remb
a=rtcp-fb:* nack
a=mid:1

If Docker is involved, that’s not something I’m going to touch - sorry. That’s most likely the issue in some way.

Haha fair enough, although I wouldn’t have thought that would be the case as we are using network_mode=host which means our container sees the host’s network interfaces. So Docker shouldn’t interfere with networking.

Regardless, I will try extract things from the Docker container and see how we get on. Either way we will get some more info.

Thanks for your help.
Josh

Hi Joshua,

We have removed Docker from the equation and the result is very similar.
At the bottom of this message is an example call to Asterisk 18.8 that is running on the Host OS (not in Docker) - Ubuntu 20:04.

For completeness here is the flow for the Invite:
client --websocket–> opensips --sip(tcp/ipv4)–> asterisk
The below SIP trace happens on the Opensips<->Asterisk leg.

Please see my above message for the ip addr and Asterisk config as that hasn’t changed.
All IP addresses are the same as we are using the same box for this test as before.

The call works okay over IPv4 however we are trying to get it working over IPv6. We thought a good first step was to at least get Asterisk responding with some IPv6 candidates.

Perhaps there are some settings we need to change in pjsip.conf or rtp.conf?

Interestingly, as a sidenote, if I add a line with external_media_address=2600:1900:40b0:1xxx:: to the transport section of pjsip.conf, I get this in the OK response from Asterisk. (xxx’s are obviously not included in public IP’s). Is this normal?

v=0
o=- 1293213110 4 IN IP4 [2600:1900:40b0:1xxx::]
s=Asterisk
c=IN IP4 [2600:1900:40b0:1xxx::]
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1
m=audio 19282 UDP/TLS/RTP/SAVPF 111 0 8 126
a=connection:new
a=setup:active
a=fingerprint:SHA-256 3D:9D:4B:B5:88:F5:89:61:08:1E:05:AD:A3:3F:B1:02:C8:28:D1:D1:CC:91:0B:5C:9E:F5:5C:3C:A6:E0:0B:06
a=ice-ufrag:180289056413518505b2e66068c6eb07
a=ice-pwd:xxx
a=candidate:H23c5be0e 1 UDP 2130706431 35.197.xx.xx 19282 typ host
a=candidate:Hac110001 1 UDP 2130706431 172.17.0.1 19282 typ host
a=candidate:Hac150001 1 UDP 2130706431 172.21.0.1 19282 typ host
a=candidate:Hac160001 1 UDP 2130706431 172.22.0.1 19282 typ host

Cheers,
Josh

Example call with same settings as previous message just not in Docker

INVITE sip:+61xxxx@xxx.vxt.co.nz SIP/2.0
Via:  SIP/2.0/TCP 10.152.0.3:5265;branch=z9hG4bKf1ee.3c33a504.0;i=97889264
To:  <sip:+61xxxx@xxx.vxt.co.nz>
From:  <sip:webrtc_client@xxxx.vxt.co.nz>;tag=hjv0v81dvc
CSeq:  1 INVITE
Call-ID: svljtk1ll3ja2cnoqmrr
Max-Forwards:  69
X-Vxt-User-Id:  xxx
X-Vxt-User-Token:  xxx
X-Vxt-Inbox-Id:  +64xxx
X-Vxt-Call-Id:  xxx
X-Vxt-Platform:  web/0.0.0-latest (xxx)
Contact:  <sip:3r7o1t9j@10.152.0.3:5265;transport=tcp;thinfo=xxx
Allow:  ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported:  outbound
User-Agent:  SIP.js/0.20.0
Content-Type:  application/sdp
Content-Length:  7006
X-Vxt-Location:  xxx
X-Vxt-Invite-Source:  xxx
X-Vxt-Original-Domain:  xxx

v=0
o=- 2516864729573174431 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic:  WMS c44b3cd1-bb2b-42e2-8320-8743ffc5b3ae
m=audio 34537 UDP/TLS/RTP/SAVPF 111 63 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 10.129.0.2
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3655964491 1 udp 2122262783 2600:1900:40b0:fxxx::  56284 typ host generation 0 network-id 2
a=candidate:3757563338 1 udp 2122194687 10.129.0.2 34537 typ host generation 0 network-id 1
a=candidate:2540334011 1 tcp 1518283007 2600:1900:40b0:fxxx::  9 typ host tcptype active generation 0 network-id 2
a=candidate:2440307002 1 tcp 1518214911 10.129.0.2 9 typ host tcptype active generation 0 network-id 1
a=ice-ufrag:wloG
a=ice-pwd:xxx
a=ice-options:trickle
a=fingerprint:sha-256 EA:23:D9:BE:46:74:52:CD:84:76:B4:6C:D0:C2:99:01:2A:9B:7F:B3:64:DC:05:99:D9:F7:17:D9:BE:75:6D:7F
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:c44b3cd1-bb2b-42e2-8320-8743ffc5b3ae 884d469c-9766-44a3-82da-8a5d32253fcd
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
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:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:1331883837 cname:WDOLAF85Rl4Dw2wJ
a=ssrc:1331883837 msid:c44b3cd1-bb2b-42e2-8320-8743ffc5b3ae 884d469c-9766-44a3-82da-8a5d32253fcd
m=video 44762 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 35 36 37 38 102 123 127 122 125 107 108 109 124 121 39 40 41 42 43 44 45 46 120 119 114 47
c=IN IP4 10.129.0.2
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3655964491 1 udp 2122262783 2600:1900:40b0:fxxx::  49962 typ host generation 0 network-id 2
a=candidate:3757563338 1 udp 2122194687 10.129.0.2 44762 typ host generation 0 network-id 1
a=candidate:2540334011 1 tcp 1518283007 2600:1900:40b0:fxxx::  9 typ host tcptype active generation 0 network-id 2
a=candidate:2440307002 1 tcp 1518214911 10.129.0.2 9 typ host tcptype active generation 0 network-id 1
a=ice-ufrag:wloG
a=ice-pwd:xxx
a=ice-options:trickle
a=fingerprint:sha-256 EA:23:D9:BE:46:74:52:CD:84:76:B4:6C:D0:C2:99:01:2A:9B:7F:B3:64:DC:05:99:D9:F7:17:D9:BE:75:6D:7F
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:35 VP9/90000
a=rtcp-fb:35 goog-remb
a=rtcp-fb:35 transport-cc
a=rtcp-fb:35 ccm fir
a=rtcp-fb:35 nack
a=rtcp-fb:35 nack pli
a=fmtp:35 profile-id=1
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:37 VP9/90000
a=rtcp-fb:37 goog-remb
a=rtcp-fb:37 transport-cc
a=rtcp-fb:37 ccm fir
a=rtcp-fb:37 nack
a=rtcp-fb:37 nack pli
a=fmtp:37 profile-id=3
a=rtpmap:38 rtx/90000
a=fmtp:38 apt=37
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:123 rtx/90000
a=fmtp:123 apt=102
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=124
a=rtpmap:39 H264/90000
a=rtcp-fb:39 goog-remb
a=rtcp-fb:39 transport-cc
a=rtcp-fb:39 ccm fir
a=rtcp-fb:39 nack
a=rtcp-fb:39 nack pli
a=fmtp:39 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=4d001f
a=rtpmap:40 rtx/90000
a=fmtp:40 apt=39
a=rtpmap:41 H264/90000
a=rtcp-fb:41 goog-remb
a=rtcp-fb:41 transport-cc
a=rtcp-fb:41 ccm fir
a=rtcp-fb:41 nack
a=rtcp-fb:41 nack pli
a=fmtp:41 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=f4001f
a=rtpmap:42 rtx/90000
a=fmtp:42 apt=41
a=rtpmap:43 H264/90000
a=rtcp-fb:43 goog-remb
a=rtcp-fb:43 transport-cc
a=rtcp-fb:43 ccm fir
a=rtcp-fb:43 nack
a=rtcp-fb:43 nack pli
a=fmtp:43 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=f4001f
a=rtpmap:44 rtx/90000
a=fmtp:44 apt=43
a=rtpmap:45 AV1/90000
a=rtcp-fb:45 goog-remb
a=rtcp-fb:45 transport-cc
a=rtcp-fb:45 ccm fir
a=rtcp-fb:45 nack
a=rtcp-fb:45 nack pli
a=rtpmap:46 rtx/90000
a=fmtp:46 apt=45
a=rtpmap:120 red/90000
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=120
a=rtpmap:114 ulpfec/90000
a=rtpmap:47 flexfec-03/90000
a=rtcp-fb:47 goog-remb
a=rtcp-fb:47 transport-cc
a=fmtp:47 repair-window=10000000
SIP/2.0 200 OK
Via:  SIP/2.0/TCP 10.152.0.3:5265;rport=49009;received=10.152.0.3;branch=z9hG4bKf1ee.3c33a504.0;i=97889264
Call-ID: svljtk1ll3ja2cnoqmrr
From:  <sip:webrtc_client@xxx.vxt.co.nz>;tag=hjv0v81dvc
To:  <sip:+61xxxxxxxx@xxx.vxt.co.nz>;tag=4f6577c3-feb5-42bc-9b7b-4e72c1bcf726
CSeq:  1 INVITE
Server:  Asterisk PBX 18.8.0
Contact:  <sip:10.152.0.3:6001;transport=TCP>
Allow:  OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported:  100rel, timer, replaces, norefersub
Content-Type:  application/sdp
Content-Length:   1712

v=0
o=- 4192939167 4 IN IP4 10.152.0.3
s=Asterisk
c=IN IP4 10.152.0.3
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1
m=audio 13866 UDP/TLS/RTP/SAVPF 111 0 8 126
a=connection:new
a=setup:active
a=fingerprint:SHA-256 93:60:E9:1D:D4:4C:AD:FA:E2:88:92:9D:0A:C5:95:97:61:4A:12:9D:FE:93:49:D1:75:8C:07:D2:68:63:E9:F6
a=ice-ufrag:5081549f03fadbee610950792680c8da
a=ice-pwd:xxx
a=candidate:H23c5be0e 1 UDP 2130706431 35.197.xx.xx 13866 typ host
a=candidate:Hac110001 1 UDP 2130706431 172.17.0.1 13866 typ host
a=candidate:Hac150001 1 UDP 2130706431 172.21.0.1 13866 typ host
a=candidate:Hac160001 1 UDP 2130706431 172.22.0.1 13866 typ host
a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux
a=ssrc:1809547742 cname:516b64be-2f14-4b8a-91d0-2c8e0ea57a6e
a=msid:d5c9f724-21e4-49e9-aa3a-88c8d99837ba 64841076-38dd-4110-ad87-c6bb98d5efc8
a=rtcp-fb:* transport-cc
a=mid:0
m=video 13866 UDP/TLS/RTP/SAVPF 102
a=connection:new
a=setup:active
a=fingerprint:SHA-256 93:60:E9:1D:D4:4C:AD:FA:E2:88:92:9D:0A:C5:95:97:61:4A:12:9D:FE:93:49:D1:75:8C:07:D2:68:63:E9:F6
a=ice-ufrag:5081549f03fadbee610950792680c8da
a=ice-pwd:xxx
a=rtpmap:102 H264/90000
a=fmtp:102 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001F
a=sendonly
a=rtcp-mux
a=ssrc:1317388575 cname:81a7d745-9158-4f46-ac55-a2282c618e5b
a=msid:7209ad61-b206-480d-a8e8-eceea4f64ec5 d8f3c281-47a3-4121-9aef-aff7bb47c51d
a=rtcp-fb:* transport-cc
a=rtcp-fb:* ccm fir
a=rtcp-fb:* goog-remb
a=rtcp-fb:* nack
a=mid:1

Yes, if setting external_media_address then you would get the non-ICE SDP part you’re seeing since you’re explicitly setting the c= line.

I don’t know why IPv6 candidates would not be getting added, but the specific line is here[1] that retrieves them from the system.

[1] asterisk/res_rtp_asterisk.c at 18 · asterisk/asterisk · GitHub

Awesome thanks for your help.

After a decent amount of research we found the solution to be the following patch. This patch makes it seem to Asterisk that the signaling is done over IPv6 even though it is not. The RTP socket is then bound to AF_INET6 which can receive IPv4 and IPv6 traffic.

--- res/res_rtp_asterisk.c
+++ res/res_rtp_asterisk.c
@@ -4032,7 +4032,14 @@ static int ast_rtp_new(struct ast_rtp_instance *instance,
 	rtp->expectedrxseqno = -1;
 	rtp->expectedseqno = -1;
 	rtp->sched = sched;
-	ast_sockaddr_copy(&rtp->bind_address, addr);
+	// ast_sockaddr_copy(&rtp->bind_address, addr);
+	// Since we do signaling (SIP) over IPv4, but want to do audio (RTP) over both IPv4/IPv6 we
+	// set the bind addr to be the IPv6 'any' address which is conveniently all 0's.
+	// By binding to this address we are able to receive RTP packets over either IPv4 or IPv6.
+	// We don't worry that the port is also all 0's as RTP will choose its own port.
+	rtp->bind_address.len = sizeof(struct sockaddr_in6);
+	memset(&rtp->bind_address.ss, 0, sizeof(struct sockaddr_in6));
+	rtp->bind_address.ss.ss_family = AF_INET6;

 	/* Transport creation operations can grab the RTP data from the instance, so set it */
 	ast_rtp_instance_set_data(instance, rtp);

Do you think there could be any glaring problems with this approach at first glance?

Kind Regards,
Josh

Do you actually understand why that fixes it, or what the original problem was? For example - what is the value of addr that was passed in? The res_pjsip_sdp_rtp code will use “::” or “0.0.0.0” depending on whether the system is capable of IPv6 or not. If it doesn’t think the system is capable of IPv6, then that would be the issue and where the fix should be.

From a general sense your change generally violates the opaqueness of ast_sockaddr which should be avoided and the ast_sockaddr functions used instead.

Aha, you have a transport specified on the endpoint which is likely triggering this:

Remove the transport from the endpoint and it’ll go to any instead. You don’t need to specify the transport.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.