[sr-dev] STUN FINGERPRINT attribute missing?

[Richard Fuchs]

On 10/22/14 16:53, Peter Villeneuve wrote:
> 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.

The best way to find out what could be going on is to post the complete
log from rtpengine for one such call. This will show all the SDP bodies
and everything else involved.

cheers