Hi,<br><br>Thanks for your response <br>My pipeline is as below:<br><br>fakesink <---- rtppcmudepay <---- gstrtpbin <--- udpsrc<br><br>do you mean that the source pad in the downstream element (which I<br>
suppose being a rtppcmudepay) is receiving buffer with those payloads?<br>
How did you detect such a behaviour?<br><br><span style="color: rgb(51, 0, 153);">---->Logs shows that gstrtbin is receiving rtp packets with different payload and looking for element for linking.</span><br>
<br>
As a further note, if your sending side is using the same port for<br>
PCMU and DTMF there may something wrong in its configuration.<br><br><span style="color: rgb(51, 0, 153);">---->No, This behaviour is right as per standard. Sender can use same port for RTP Audio (PCMU) and DTMF (RFC 2833)/ </span><br>
<br>Thanks<br><div class="gmail_quote">On Mon, Dec 27, 2010 at 1:46 PM, Marco Ballesio <span dir="ltr"><<a href="mailto:gibrovacco@gmail.com">gibrovacco@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
it's not too clear how you're trying to get your data on the receiving<br>
pipeline. Can you post the structure of the pipeline you're using?<br>
Some more comments below.<br>
<div class="im"><br>
On Mon, Dec 27, 2010 at 8:21 AM, Umakant Goyal <<a href="mailto:umakantgoyal1@gmail.com">umakantgoyal1@gmail.com</a>> wrote:<br>
> Hi All,<br>
><br>
> I am making pipeline using gstrtpbin, rtppcmudepay, udpsrc and fakesink<br>
> elements to receive RTP audio stream from network. Everything goes fine when<br>
> i receive audio(pcmu) rtp packets with payload type 0 and encdoing-name<br>
> PCMU. But my pipeline breaks when i receive CN (comfort noise) rtp packets<br>
> with payload type 13 and dtmf packets with payload type 101. I have tried<br>
> lot to ignore these packets but i did not succeed to find out the solution<br>
> of my problem. Please help me by telling the possible solutions of my<br>
> problem.<br>
<br>
</div>can you collect a backtrace of the crash? It should be fairly easy<br>
with the aid of GDB.<br>
<div class="im"><br>
><br>
> I am also wondering why udpsrc element is receiving rtp messages with<br>
> payload 101 and 13 because i have set the caps for udpsrc as given below:<br>
><br>
> media --> audio,<br>
> payload --> 0,<br>
> clock-rate --> 8000<br>
> encoding-name --> PCMU,<br>
<br>
</div>do you mean that the source pad in the downstream element (which I<br>
suppose being a rtppcmudepay) is receiving buffer with those payloads?<br>
How did you detect such a behaviour?<br>
<br>
As a further note, if your sending side is using the same port for<br>
PCMU and DTMF there may something wrong in its configuration.<br>
<div class="im"><br>
><br>
> As per my understanding if i would set the above given caps to udpsrc then<br>
> it should ignore other rtp packets except with payload 0 and encoding-name<br>
> PCMU.<br>
><br>
> Thanks<br>
</div>> ------------------------------------------------------------------------------<br>
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers<br>
> to consolidate database storage, standardize their database environment,<br>
> and,<br>
> should the need arise, upgrade to a full multi-node Oracle RAC database<br>
> without downtime or disruption<br>
> <a href="http://p.sf.net/sfu/oracle-sfdevnl" target="_blank">http://p.sf.net/sfu/oracle-sfdevnl</a><br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br>
><br>
><br>
<br>
------------------------------------------------------------------------------<br>
Learn how Oracle Real Application Clusters (RAC) One Node allows customers<br>
to consolidate database storage, standardize their database environment, and,<br>
should the need arise, upgrade to a full multi-node Oracle RAC database<br>
without downtime or disruption<br>
<a href="http://p.sf.net/sfu/oracle-sfdevnl" target="_blank">http://p.sf.net/sfu/oracle-sfdevnl</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br>
</blockquote></div><br>