I can't tell you for sure what is happenning because I haven't gone in the
sources that deep, but the overview is that in prepare_pcap.c it reads your
pcap data and store it in some buffer and in send_packets.c it gets your
data, packs in UDP/RTP and sends it to the wire, so I recommend you to study
these two files to understand the full process!
By having a quick look in the code I found this in send_packets() func:
while (pkt_index < pkt_max) {
memcpy(udp, pkt_index->data, pkt_index->pktlen);
port_diff = ntohs (udp->uh_dport) - pkts->base;
// modify UDP ports
udp->uh_sport = htons(port_diff + *from_port);
udp->uh_dport = htons(port_diff + *to_port);
....
so my guess is that you have to handle this port_diff, since it seems to be
calculated from the packets of your pcap, as you have observed!
On Mon, Oct 17, 2011 at 1:48 PM, Greg Horton <greg.hor...@dialogic.com>wrote:
> Hi,****
>
> ** **
>
> Well I made the changes in the spot we discussed (see below) but SIPp is
> still playing the .pcap file I gave it with a +2 offset for the video
> stream. Both source and destination UDP ports are set to +2 from the audio
> streams. In the script I am using +4 for auto_media_port offset. With the
> changes we previously talked about, we would open up sockets and bind to the
> +4 offset but it does not seem like that is relating to how we are
> generating packets from the .pcap file I gave it. ****
>
> ** **
>
> One thing to note about my .pcap file is that the original file I give SIPp
> to play did use +2 offsets (Kapanga Wireshark capture). Is it possible that
> PCAPPLAY retains the original offset between audio & video as what was in
> the original .pcap file, but does replace the port numbers with the base
> port configured for SIPp? In my case, the original .pcap file I had this:
> ****
>
> ** **
>
> AUDIO****
>
> srcPort 15100****
>
> dstPort 5100****
>
> VIDEO****
>
> srcPort 15102****
>
> dstPort 5102****
>
> ** **
>
> In SIPp UAC I set –mp 30000 and the GW that UAC talks to (my product) sends
> m=audio 8192 and m=video 8196. Then in the new Wireshark trace I see:****
>
> ** **
>
> AUDIO****
>
> srcPort 30000****
>
> dstPort 8192****
>
> VIDEO****
>
> srcPort 30002****
>
> dsptPort 8194****
>
> ** **
>
> So any idea where in SIPp code the .pcap is played and port offsets are
> mapped? ****
>
> ** **
>
> I did rebuild all of Windows SIPp in Cygwin (after “make clean”) twice with
> the modification we talked about and checked timestamps of .o and .exe files
> and it seems like it should be working.****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Greg****
>
> ** **
>
> On Fri, Oct 14, 2011 at 1:01 PM, Greg Horton <greg.hor...@dialogic.com>
> wrote:****
>
> Yes, it looks like it’s here:****
>
> ****
>
> */*---------------------------------------------------------
> Bind the second socket to media_port+2
> (+1 is reserved for RTCP)
> ----------------------------------------------------------*/*
>
> *if* (media_sockaddr*.*ss_family *==* AF_INET) {
> (*_RCAST*(*struct* sockaddr_in *,&media_sockaddr))*->*sin_port *=*
> *htons*((*short*)media_port*+*2);
> *strcpy*(media_ip_escaped, media_ip);
> } *else* {
> (*_RCAST*(*struct* sockaddr_in6 *,&media_sockaddr))*->*sin6_port *=*
> *htons*((*short*)media_port*+*2);
> media_ip_is_ipv6 *=* *true*;
> *strcpy*(media_ip_escaped, media_ip);
> }
>
> *if*(*bind*(media_socket_video,
> (sockaddr *)(*void* *)&media_sockaddr,
> *SOCK_ADDR_SIZE*(&media_sockaddr))) {
> *char* msg[512];
> *sprintf*(msg, "Unable to bind video RTP socket (IP=%s, port=%d)",
> media_ip, media_port*+*2);
> *ERROR_NO*(msg);
> }****
>
> That’s great! I will try it out and update the thread. Not sure how the
> hardcoded “+2” could be replaced with a configurable variable??****
>
>
> Thank you!****
>
> ****
>
> *Greg Horton*****
>
> Embedded Software Engineer****
>
> ****
>
> Dialogic Research Inc.
> 75 Perseverance Way****
>
> Hyannis, MA 02601 USA
>
> Tel: 508 862 3591
> Email: greg.hor...@dialogic.com <briane.ritc...@dialogic.com>
> Web: www.dialogic.com
>
> This e-mail is intended only for the named recipient(s) and may contain
> information that is privileged, confidential and/or exempt from disclosure
> under applicable law. No waiver of privilege, confidence or otherwise is
> intended by virtue of communication via the internet. Any unauthorized use,
> dissemination or copying is strictly prohibited. If you have received this
> e-mail in error, or are not named as a recipient, please immediately notify
> the sender and destroy all copies of this e-mail.****
>
> ****
>
> *From:* Patrick Wakano [mailto:pwak...@gmail.com]
> *Sent:* Friday, October 14, 2011 10:40 AM
> *To:* Greg Horton
> *Cc:* sipp-users@lists.sourceforge.net
> *Subject:* Re: [Sipp-users] Need to change video port offset from
> auto_media_port****
>
> ****
>
> If you haven't found this by yourself yet, I think the decision to get the
> video port as audio port + 2 is done near the end of the main function of
> sipp.cpp as well as the logic for the echo****
>
> ****
>
> ****
>
> On Wed, Oct 12, 2011 at 4:58 PM, Greg Horton <greg.hor...@dialogic.com>
> wrote:****
>
> Hi,****
>
> ****
>
> I am trying to use SIPp for multimedia files to test my platform. On UAC I
> use PCAPPLAY and on the UAS side I want to use rtp-echo to echo back
> audio+video ports. I am using SIPp for Windows (version 3.2) which I
> compiled myself and integrated PCAPPLAY.****
>
> ****
>
> The problem I am seeing is this:****
>
> ****
>
> I define “auto_media_port” for m=audio port in SIPp SDP and
> “auto_media_port+4” for m=video port in SIPp SDP (UAC side). I see SIP
> negotiation use these ports, but when PCAPPLAY starts (playing a file with
> synchronized audio & video RTP streams) it uses auto_media_port for audio
> stream and auto_media_port+2 for video stream. So that is the first issue.
> ****
>
> ****
>
> Then, on the UAS side, I also setup SIPp SDP to use +4 for video and that
> negotiates fine. However, I see by the SIPp help comments that rtp-echo
> will reflect the audio but video only if the port is audio+2. This is
> verified in testing where audio is reflected back but not video.****
>
> ****
>
> So in the SIPp source code I would like to change the PCAPLAY and rtp-echo
> hardcoded offsets from +2 to +4. Looking in the send_packets.c and
> prepare_pcap.c files I do not see where the +2 offset is used now. These
> files are only for UAS PCAPPLAY anyways. I also need to find the source for
> where rtp-echo is handled.****
>
> ****
>
> I need this because my system (that sits between UAC and UAS) always uses a
> +4 offset for video RTP streams (and negotiates that in SIP, which SIPp is
> fine with).****
>
> ****
>
> Also, I am not sure if the Windows source is any different than the Linux
> version of SIPp in this area?****
>
> ****
>
> Thanks,****
>
> ****
>
> *Greg Horton*****
>
> Embedded Software Engineer****
>
> ****
>
> Dialogic Research Inc.****
>
> ****
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Sipp-users mailing list
> Sipp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sipp-users****
>
> ****
>
> ** **
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
