Hi, Do you have any piece of network equipment which could be mangling SIP packets in the path? On 25 Jun 2014, at 21:44, Eeri Kask <Eeri.Kask at mailbox.tu-dresden.de> wrote: > Hello, > > audio communications quality of ICE-configured link on a local network > is flawless but studying the pjsua logs it appears there is something > counter-intuitive: if host A calls host B, then ICE session is > established as expected, until the point host B receives a final > "UPDATE" request from A with the nominated link configuration in SDP: > > a=candidate:Hc0a80064 1 UDP 1694498815 192.168.0.100 4007 typ host > a=remote-candidates:1 192.168.0.200 4006 > > (192.168.0.100 is host A, 192.168.0.200 is host B). > > Here host B apparently doesn't understand this request: > > Processing SDP: support ICE=1, common comp_cnt=1, ice_mismatch=1, > ice_restart=0, local_role=Controlled > Stopping ICE, reason=Remote offer mismatch: :Default target doesn't > match any ICE candidates (PJNATH_EICEMISMATCH) > > > and replies with > > a=ice-mismatch > > which leads to > > Stopping ICE, reason=Remote answer doesn't support ICE > > on host A. > > > Nevertheless the media link (a direct link, not through a distant > sip-relay!) is up and functional between A and B until the call is > terminated by a BYE. > > Finally, pjsua was started as > > pjsip-apps/bin/pjsua \ > --nameserver=192.168.0.1 \ > --stun-srv=stun.stunprotocol.org \ > --use-ice --ice-no-rtcp --no-tcp > > on both sides (i.e. in aggressive mode, but --regular doesn't change > anything, in the final UPDATE stage B still complains about "remote > offer mismatch"). > > 1. Is there anything wrong? (Transmitted sound quality is perfect!) > 2. If 'y', then how this can be fixed? > > P.S. A detailed log is attached. > > Eeri Kask > > <ice_bug_report.txt>_______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -- Sa?l Ibarra Corretg? AG Projects
