As the pcapplay doesn't care what codec is the payload of the packets it replays, I assume the issue is different.
Just a bunch of points I would look at: - does the same happen with another codec, like PCMA? - the G.722 packets in the pcap file you replay bear some payload type number. If the receiving side has assigned another payload type number to that codec in its SDP, I'm not sure whether SIPp respects that and modifies anything in the contents of the RTP portion of the replayed packets prior to sending them. - there may be some misunderstanding regarding G.722, G.722.1 and G.722.2 - they are different (mutually incompatible) codecs and for the latter two, no fixed payload type number has been registered. - if you replay exactly the same pcap file for all conference participants, the conference bridge may get confused by receiving several streams from different source sockets with the same SSRC, as SIPp does not modify SSRC while replaying a pcap. Use tcpdump or Wireshark/tshark to check whether and where does SIPp actually send the RTP and what the payload type number is. Pavel ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
