<div dir="ltr">Thanks Richard.<div><br></div><div>I guess I'll have to keep looking then.</div><div><br></div><div>Have there been any changes in the syntax for rtpengine and its integration with Kamailio 4.2 lately?</div><div><br></div><div>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.</div><div><br></div><div>I have the following in my kamailio config</div><div><br></div><div><div># RTPProxy control</div><div>route[NATMANAGE] {</div><div>#!ifdef WITH_NAT</div><div><span class="" style="white-space:pre">       </span>if (is_request()) {</div><div><span class="" style="white-space:pre">                </span>if(has_totag()) {</div><div><span class="" style="white-space:pre">                  </span>if(check_route_param("nat=yes")) {</div><div><span class="" style="white-space:pre">                               </span>setbflag(FLB_NATB);</div><div><span class="" style="white-space:pre">                        </span>}</div><div><span class="" style="white-space:pre">          </span>}</div><div><span class="" style="white-space:pre">  </span>}</div><div><span class="" style="white-space:pre">  </span>if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))</div><div><span class="" style="white-space:pre">                </span>return;</div><div><br></div><div><span class="" style="white-space:pre">   </span>rtpengine_manage("replace-origin replace-session-connection");</div><div><span class="" style="white-space:pre">   </span></div><div><br></div><div><span class="" style="white-space:pre">  </span>if (is_request()) {</div><div><span class="" style="white-space:pre">                </span>if (!has_totag()) {</div><div><span class="" style="white-space:pre">                        </span>if(t_is_branch_route()) {</div><div><span class="" style="white-space:pre">                          </span>add_rr_param(";nat=yes");</div><div><span class="" style="white-space:pre">                        </span>}</div><div><span class="" style="white-space:pre">          </span>}</div><div><span class="" style="white-space:pre">  </span>}</div><div><span class="" style="white-space:pre">  </span>if (is_reply()) {</div><div><span class="" style="white-space:pre">          </span>if(isbflagset(FLB_NATB)) {</div><div><span class="" style="white-space:pre">                 </span>if(is_first_hop())</div><div><span class="" style="white-space:pre">                         </span>set_contact_alias();</div><div><span class="" style="white-space:pre">               </span>}</div><div><span class="" style="white-space:pre">  </span>}</div><div>#!endif</div><div><span class="" style="white-space:pre">    </span>return;</div><div>}</div></div><div><br></div><div>Does anything jump out at you as being wrong?</div><div><br></div><div>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.</div><div>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.</div><div>However, if one is behind symmetric NAT than rtpengine should be called in to relay the media.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Anyway, I don't need to be spoon fed, but a push in the right direction would be much appreciated.</div><div><br></div><div>Thanks,</div><div><br></div><div>Peter</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 9:00 PM, Richard Fuchs <span dir="ltr"><<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/22/14 15:48, Peter Villeneuve wrote:<br>
> Hi,<br>
><br>
> I just updated to 4.2 stable along with latest rtpengine module compiled<br>
> today from git.<br>
><br>
> I'm also running latest (compiled today) RFC5766 turn server on the same<br>
> Debian 7 host.<br>
><br>
> I noticed that sometimes I get one way audio with linphone client in<br>
> Android, and looking through the logs I see these STUN error messages:<br>
><br>
> rtpengine[4633]: [port 10448] Not handling potential STUN packet from<br>
> 85.xx.xx.xx:7076: FINGERPRINT attribute missing<br>
><br>
> That 85.xx.xx.xx address is indeed the public IP of the linphone client.<br>
><br>
> Looking further in the RTP engine logs you can see it's not getting the<br>
> IP which I believe would explain the 1 way audio issues.<br>
><br>
> Media #1, port 10468 <>            [::]:0    , 0 p, 0 b, 0 e<br>
><br>
><br>
> Now why would rtpengine be dealing with STUN packets at all? I imagine<br>
> the RFC5766 stun server would handle that completely.<br>
><br>
> I guess the more I dig, the more confused I get. Has anything changed<br>
> recently in rtpengine or kamailio 4.2 to produce this behavior?<br>
<br>
</div></div>This is part of ICE (RFC 5245 and RFC 5389). If ICE is enabled,<br>
rtpengine will listen for and handle STUN packets, which in this context<br>
require the fingerprint attribute.<br>
<br>
I don't think this explains your 1-way audio issue though. From the log<br>
message you posted, I suspect that no "answer" was received by rtpengine.<br>
<br>
cheers<br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</blockquote></div><br></div>