Is it possible that Asterisk doesn't remove candidates info and let clients do p2p setup themselves?

Hi, I tried to set up p2p between 2 imsdroid which supports ice, stun, turn itself, but asterisk will remove candidates info from original INVITE messages. is it possible that Asterisk doesn’t remove candidates info and let clients do p2p based on candidates info? I tried asterisk directrtpsetup, directmedia, it couldn’t work as good as it should be. sometimes there is no video or audio at all, which means the p2p behavior is not correct. Asterisk should have taken public IP, turn relay IP in candidates info into consideration if it really wants to help clients set up p2p instead of just removing candidates info, which leaves clients no option.

here is the INVITE, I read some codes in chan_sip.c, it seems it will add ice to sdp at some point, I’m not sure what I missed in the INVITE message, which prevents ice from being added to sdp. Please help me out. Thanks a lot

INVITE sip:1002@114.55.34.177 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.103:65391;branch=z9hG4bK-1201740443;rport

From: "A"sip:1006@114.55.34.177;tag=736959614

To: sip:1002@114.55.34.177

Contact: sip:1006@192.168.1.103:65391;transport=udp;+g.oma.sip-im;language=“en,cn”;+g.3gpp.icsi-ref=“urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”

Call-ID: b5d93d62-8ffb-da8f-1445-ddbeed6c8b7d

CSeq: 1497310136 INVITE

Content-Type: application/sdp

Content-Length: 1846

Max-Forwards: 70

Accept-Contact: *;+g.3gpp.icsi-ref=“urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”

P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK, UPDATE, REFER

Privacy: none

P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000

User-Agent: IM-client/OMA1.0 ios-ngn-stack/v00 (doubango r000)

P-Preferred-Identity: sip:1006@114.55.34.177

v=0

o=newayte 1983 678902 IN IP4 192.168.1.103

s=-

c=IN IP4 192.168.1.103

t=0 0

a=tcap:1 RTP/AVPF

m=audio 58314 RTP/AVP 8 0 101

c=IN IP4 192.168.1.103

a=ptime:20

a=minptime:1

a=maxptime:255

a=silenceSupp:off - - - -

a=rtpmap:8 PCMA/8000/1

a=rtpmap:0 PCMU/8000/1

a=rtpmap:101 telephone-event/8000/1

a=fmtp:101 0-16

a=pcfg:1 t=1

a=sendrecv

a=rtcp-mux

a=ssrc:2138782017 cname:(null)

a=ssrc:2138782017 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2

a=ssrc:2138782017 label:newayte@audio

a=ice-ufrag:aF230kSsKloetgS

a=ice-pwd:KE4UMzNfEf0EDf7EePxGTr

a=candidate:1ZRpXAFNeBRaLbF 1 udp 2130706431 192.168.1.103 58314 typ host tr udp fd 33

a=candidate:1ZRpXAFNeBRaLbF 2 udp 2130706430 192.168.1.103 58315 typ host tr udp fd 37

a=candidate:srflx1ZRpXAFNeB 1 udp 1694498815 49.66.39.252 5143 typ srflx raddr 192.168.1.103 rport 58314 tr udp fd 33

a=candidate:srflx1ZRpXAFNeB 2 udp 1694498814 49.66.39.252 5144 typ srflx raddr 192.168.1.103 rport 58315 tr udp fd 37

m=video 53504 RTP/AVP 104

c=IN IP4 192.168.1.103

b=AS:2000

b=TIAS:2048000

a=rtcp-fb:* ccm fir

a=rtcp-fb:* nack

a=rtcp-fb:* goog-remb

a=rtcp-fb:* doubs-jcng

a=label:6

a=content:main

a=rtpmap:104 H264/90000

a=pcfg:1 t=1

a=sendrecv

a=rtcp-mux

a=ssrc:2141755105 cname:(null)

a=ssrc:2141755105 mslabel:6994f7d1-6ce9-4fbd-acfd-84e5131ca2e2

a=ssrc:2141755105 label:newayte@video

a=ice-ufrag:y18UKKHjG3V0m6B

a=ice-pwd:AMXZBxZDbIRTkp8wMS8dmF

a=candidate:my909aREceOrSdG 1 udp 2130706431 192.168.1.103 53504 typ host tr udp fd 34

a=candidate:my909aREceOrSdG 2 udp 2130706430 192.168.1.103 53505 typ host tr udp fd 35

a=candidate:srflxmy909aREce 1 udp 1694498815 49.66.39.252 5141 typ srflx raddr 192.168.1.103 rport 53504 tr udp fd 34

a=candidate:srflxmy909aREce 2 udp 1694498814 49.66.39.252 5142 typ srflx raddr 192.168.1.103 rport 53505 tr udp fd 35

I found in rtp_engine.c,
struct ast_rtp_engine_ice *ast_rtp_instance_get_ice(struct ast_rtp_instance *instance)
{
return instance->engine->ice;
}
but I didn’t find any codes to initialize engine->ice, so ice will never be added to sdp, am I right? @mjordan

Asterisk does not support passing through ICE candidates. Negotiation will always occur between the client and Asterisk itself.

Thanks for your reply, but there is a method add_ice_to_sdp in chan_sip.c, it will add ice candidate back to INVITE message if rtp engine ice exists. I assume ice candidate will be added back at some point unless that’s a useless method. I’ll try buiding asterisk with pjproject and see if it will help p2p communication anyway.

I tried asterisk bundled with pjproject, p2p doesn’t work if 2 clients are connecting 2 different routes. If I use opensips, which pass through ice candidate, p2p can work in that circumstance. Here are my settings in sip.conf and rtp.conf
sip.conf
icesupport=yes
directmedia=update,nonat
directrtpsetup=yes

rtp.conf
icesupport=yes,
stunaddr=my stun server IP,
turnaddr=my turn server IP
turnusername=turn
turnpassword=turn

if p2p couldn’t work, I don’t know if Asterisk will help relay the media. If it does, how do I set it up?

You would need to look at the traffic and understand why the ICE negotiation between Asterisk and the client is not working.

From the invite message I got from Asterisk, one is c=IN IP4 192.168.1.103, the other side is c=IN IP4 192.168.2.208, which remains unchanged and no ICE candiate generated by Asterisk at all. so there is no way I can send video/audio to that IP:port. I’m not so sure why the negotiation doesn’t work. Both of my clients are phones, the only thing I can tell is from the INVITE message.

Do I have to migrate sip.conf to pjsip.conf? Does pjsip support video? I didn’t find the option

The chan_sip module can still be used, it’s just in an extended support state which means the community responds to any issues with it. As for video support it does, but there is no explicit option to turn it on. You just have to have a video format allowed for the endpoint.