Ok so I confirmed #2 is not the issue. The payload number on the 200 OK is
the same as the INVITE from SIPP.
As for the SSRC, I did noticed two separate streams with their own unique
port having different SSRC values generated by SIPP.
On Fri, Oct 28, 2016 at 1:35 PM, Andy Chen <ac...@fuze.com> wrote:
> Thanks Pavel for the detailed response.
>
> I did do a tcpdump locally on the sipp device and I do see bi-directional
> RTP packets being exchanged, which may narrow down the issue to #2 or #3.
>
> On Fri, Oct 28, 2016 at 1:13 PM, sindelka <sinde...@ttc.cz> wrote:
>
>> 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
>>
>
>
>
> --
> Andy Chen
> Sr. Telephony Lead Engineer
> 415 516 5535 (M)
> ac...@thinkingphones.com
>
--
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
ac...@thinkingphones.com
------------------------------------------------------------------------------
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
