2009/7/7 Maxim Sobolev <[email protected]>: >> - "1.a.rtp" is one direction and "1.o.rtp" the other, right? > > Yes, that's right. Those are streams in two different directions. If my > memory serves, ".a.rtp" is stream from caller, while ".o.rtp" is stream > from callee. By the way, you might want to check PCAP recording instead > of recording in custom format ("-P" option). It's little less compact > but allows using third-party tools to analyze and decode streams.
Yes, I'm already using -P option :) However, the manpage of rtpproxy is not updated about the -P option. >> - What are the last two files? In this case they are 0 length, but in >> longer calls the are some bytes length. > > Those should be files for the second stream in media session (video?). > If you don't have video enabled then something is wrong, it would help > if you can send SDP of the offer and SDP of the corresponding answer. You are right, there is video in the SDP offer (but not in the response): SDP offer: -------------------- v=0 o=- 732835142 732835142 IN IP4 222.220.5.228 s=ENSResip c=IN IP4 222.220.32.79 t=0 0 m=audio 32624 RTP/AVP 0 18 8 3 101 a=fmtp:18 annexb=no a=fmtp:101 0-16 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=silenceSupp:off - - - - a=sendrecv m=video 32620 RTP/AVP 34 103 99 a=rtpmap:34 H263/90000 a=rtpmap:103 H263-1998/90000 a=rtpmap:99 H264/90000 a=nortpproxy:yes ------------------------- SDP response: ------------------------- v=0 o=- 1249125920 1249125920 IN IP4 222.220.5.228 s=ENSResip c=IN IP4 222.220.5.232 t=0 0 m=audio 21044 RTP/AVP 0 101 a=fmtp:101 0-15 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv ------------------------- >> PS: Is there any way to start the recording when 200 OK arrives (so >> early media is not recorded)? >> I cannot imagine how to do it since "start_recording()" must be called >> in the INVITE request (and also in the response). > > Yes, you are correct. The current nathelper API doesn't allow this to be > done. What we can do in this regard, is to implement some flag for > start_recording() to request recording of stream going in different > direction, so that you can do two subsequent calls in the 200 OK > handler, one with that flag and one without. Should be trivial thing to > do - just swap out to/from tags before passing them to the RTPproxy. I > will take a look in the next few days if nobody beats me on that. It would be really nice :) -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Devel mailing list [email protected] http://lists.rtpproxy.org/mailman/listinfo/devel
