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. _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
