Re: [sr-dev] STUN FINGERPRINT attribute missing?

Thanks Richard. I guess I'll have to keep looking then. Have there been any changes in the syntax for rtpengine and its integration with Kamailio 4.2 lately? I have quite a few of those "empty IPs" (for lack of a better word) in the rtpengine logs and I can't figure out why they occur. I have the following in my kamailio config # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; rtpengine_manage("replace-origin replace-session-connection"); if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) set_contact_alias(); } } #!endif return; } Does anything jump out at you as being wrong? My goal is to have linphone clients (android) with ICE enabled call Groundwire clients (iOS) also with ICE enabled. Both are using the same STUN server that sits on the same machine as Kamailio. Ideally rtpengine wouldn't get involved at all and would ignore the SDP since both UACs should be able to use ICE to negotiate a p2p connection between them. However, if one is behind symmetric NAT than rtpengine should be called in to relay the media. I've also tried the above config by adding rtpengine_manage("replace-origin replace-session-connection ICE=force-relay"); but I think that's made debugging even harder. I'm not sure if the problem lies with kamailio/rtpengine (or my config for them) or if it is the UACs that aren't playing nicely even though they supposedly support SIP and ICE RFCs. It seems when they call each other ICE isn't being used at all (at least linphone display shows ICE not activated) even though the media is flowing normally. Anyway, I don't need to be spoon fed, but a push in the right direction would be much appreciated.