bug report: ICE on localnet, "Controlled" host UPDATE bogus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 25 16:16:33 EDT 2014, Sa?l Ibarra Corretg? wrote:
>
> Do you have any piece of network equipment which could
> be mangling SIP packets in the path?


The spoken firewall (192.168.0.1, resp. 11.11.11.11) is all that I am
aware of.  This is a "usual" consumer DSL-modem provided by the telco.
I don't believe its smart enough to do any "higher-level" stateful
protocol transactions mangling.

Looking at the SIP-signaling (I have both, outgoing and incoming
SIP-messages at both endpoints, so its easy to see what got changed
underways) which goes through the sip-provider 22.22.22.22, I observe
nothing mangled.  The sip-provider only rewrites the <Contact:> fields
of outgoing and incoming requests/replies (replaces 192.168.0.100 with
11.11.11.11, and back) which makes sense.  (On 192.168.0.200 pjsua by
itself inserts <Contact:> which points to 11.11.11.11 so no rewrite is
necessary/done by sip-provider.)

The spoken UPDATE message arrives at 200 as it was sent from 100 (as
said, only the <Contact:> field was replaced at sip-provider); so if
there is anything wrong with the SDP part in it, its the responsibility
of pjsua at 100 for this.  (I tend to think pjsua at 100 sends a correct
SDP, i.e. it seems to make sense.)


Then, if pjsua is started with "--ice-regular", host 100 sends final
UPDATE with

    a=candidate:Sc0a80064 1 UDP 1862270975 11.11.11.11 4007 typ srflx
                                       raddr 192.168.0.100 rport 4007
    a=remote-candidates:1 11.11.11.11 4006


and upon arrival host 200 complains again with "Remote offer mismatch:
:Default target doesn't match any ICE candidates".  Though, the link
(which now goes through 11.11.11.11:4007 and 11.11.11.11:4006) conveys
media stream again flawlessly until a BYE is seen.

(In this latter case ICE succeeds on all three links: direct link,
back-looped at the firewall, and going through distant sip-provider.
The ICE-algorithm in PJSIP finally nominates the firewall-loopback due
to a priorities assignment in pjnath/src/pjnath/ice_strans.c (for the
case a stun-server is specified, probably on pjsua command line), so
overriding ICE-standard priorities given in
pjnath/src/pjnath/ice_session.c, which would otherwise again ensure the
direct link to win.)

    Eeri Kask



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux