[sr-dev] STUN FINGERPRINT attribute missing?

[Peter Villeneuve]

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.

Thanks,

Peter

On Wed, Oct 22, 2014 at 9:00 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 10/22/14 15:48, Peter Villeneuve wrote:
> > Hi,
> >
> > I just updated to 4.2 stable along with latest rtpengine module compiled
> > today from git.
> >
> > I'm also running latest (compiled today) RFC5766 turn server on the same
> > Debian 7 host.
> >
> > I noticed that sometimes I get one way audio with linphone client in
> > Android, and looking through the logs I see these STUN error messages:
> >
> > rtpengine[4633]: [port 10448] Not handling potential STUN packet from
> > 85.xx.xx.xx:7076: FINGERPRINT attribute missing
> >
> > That 85.xx.xx.xx address is indeed the public IP of the linphone client.
> >
> > Looking further in the RTP engine logs you can see it's not getting the
> > IP which I believe would explain the 1 way audio issues.
> >
> > Media #1, port 10468 <>            [::]:0    , 0 p, 0 b, 0 e
> >
> >
> > Now why would rtpengine be dealing with STUN packets at all? I imagine
> > the RFC5766 stun server would handle that completely.
> >
> > I guess the more I dig, the more confused I get. Has anything changed
> > recently in rtpengine or kamailio 4.2 to produce this behavior?
>
> This is part of ICE (RFC 5245 and RFC 5389). If ICE is enabled,
> rtpengine will listen for and handle STUN packets, which in this context
> require the fingerprint attribute.
>
> I don't think this explains your 1-way audio issue though. From the log
> message you posted, I suspect that no "answer" was received by rtpengine.
>
> cheers
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141022/db542f40/attachment.html>