On Wed, Oct 16, 2013 at 1:39 AM, <[email protected]> wrote: > Hello. > We are working on the server implementation of WebRTC and facing an > ambiguous problem with DTLS handshake between the server and Firefox > (currently testing on version 24). > Our workflow: > 1. We use sipML5 by Doubango to make test calls. > 2. STUN server is placed in local network to get correct IP and port (it > works well with Chrome, for example) > 3. We use ICE-LITE > 4. Our server is running on another computer in LAN, it waits for SIP > INVITE and responds with SIP OK and DTLS ClientHello. > 5. Server sends "setup:active" and "connection:new" in SDP > > When sipML sends INVITE to our server, we respond with the following SDP: > > 14:38:9 recv=SIP/2.0 200 OK > Via: SIP/2.0/WS > df7jal23ls0d.invalid;rport;branch=z9hG4bKhHFUsgTuKmXmWs4ha9Ad4cVpkvFsXvus > From: "name"<sip:[email protected]>;tag=S3KFkK2U94s5ldyCQc1C > To: "My Test Name"<sip:[email protected]>;tag=50113300003 > Contact: <sip:192.168.225.183:5060> > Call-ID: 45c213ac-91fd-d2bb-bee1-2c29a129194d > CSeq: 63943 INVITE > Content-Type: application/sdp > Content-Length: 579 > Record-Route: <sip:192.168.224.200:5070;transport=udp;lr;ovid=79c00bfe> > Record-Route: <sip:[email protected]:10080 > ;transport=ws;lr;ovid=79c00bfe> > User-Agent: NCC-6.9.9.some win build > Allow: ACK,BYE,CANCEL,INVITE,MESSAGE,INFO,PING,PRACK > Supported: early-session,100rel > Accept: application/dtmf-relay > > v=0 > o=- 1381912623 1381912623 IN IP4 192.168.225.183 > s=NauPhone > c=IN IP4 192.168.225.183 > t=1381912623 0 > a=ice-lite > a=fingerprint:sha-256 > 02:F0:00:E9:83:30:90:DA:94:2C:44:E1:88:28:AA:10:AD:49:E4:23:2F:D6:F8:6B:1E:09:8F:86:DA:6A:D0:97 > a=setup:active > a=connection:new > m=audio 5060 UDP/TLS/RTP/SAVPF 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=silenceSupp:off - - - - > a=SSRC:49300008 > a=candidate:3085019328 1 UDP 2130706431 192.168.225.183 5060 typ host > a=ice-ufrag:BF0B3806 > a=ice-pwd:FA73D4D6F480BC4C0E86875017E2D1BD > a=rtcp-mux > > After this, we are sending ClientHello (using OpenSSL, by the way) to > Firefox immediately and we don't get any response. > We've tried enabling Firefox logging for 'mtransport' module (mtranport:9) > to get more information on this problem. > But all we have got is this: > > 6556[120f530]: NrIceCtx(PC:816211c9fc98c71e): state 0->1 > 6556[120f530]: Gathered all ICE candidates for 'PC:816211c9fc98c71e' > 6556[120f530]: NrIceCtx(PC:816211c9fc98c71e): state 1->2 > 0[120f140]: ICE ctx PC:816211c9fc98c71e setting controlling to0 > 6556[120f530]: NrIceCtx(PC:816211c9fc98c71e): state 2->3 > 6556[120f530]: Flow[816211c9fc98c71e:1,rtp(none)]; Layer[ice]: Inserted: > downward='none' > 6556[120f530]: Flow[816211c9fc98c71e:1,rtp(none)]; Layer[dtls]: Inserted: > downward='ice' > 6556[120f530]: Setting up DTLS as server > 6556[120f530]: Flow[816211c9fc98c71e:1,rtcp(none)]; Layer[ice]: Inserted: > downward='none' > 6556[120f530]: Flow[816211c9fc98c71e:1,rtcp(none)]; Layer[dtls]: Inserted: > downward='ice' > 6556[120f530]: Setting up DTLS as server > 6556[120f530]: Flow[816211c9fc98c71e:1,rtp(none)]; Layer[ice]: > PacketReceived(816211c9fc98c71e/stream1/audio,1,194) > 6556[120f530]: Flow[816211c9fc98c71e:1,rtp(none)]; Layer[dtls]: > PacketReceived(194) > 6556[120f530]: Flow[816211c9fc98c71e:1,rtp(none)]; Layer[dtls]: Discarding > packet in inappropriate state > 6556[120f530]: Destroying ICE ctx 'PC:816211c9fc98c71e' > > As we found in source code, the message "Discarding packet in > inappropriate state" means that we _probably_ haven't done the ICE workflow > yet and > DTLS transport layer is not in "open" state to receive DTLS messages. >
Yes, that sounds right. I don't see any sign that ICE is completing. What does Wireshark show? -Ekr _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
