[SR-Users] rtpproxy not forwarding rtp packets.
Daniel Grotti
dgrotti at sipwise.com
Fri May 18 16:44:04 CEST 2018
Hi Aqs,
rtpproxy should start relaying immediately to the port specified in the
SDP. If the UA sends UDP packets from another source:IP port, it should
update internal session data, so that all subsequent packets will be
relayed to the proper IP:port. Otherwise it will continue to user the
same IP:port specified in the SDP.
Is the IP in the SDP negotiation correct (the public one, and not the
local one) ?
Have you had a look at the rtpproxy log ?
Daniel
On 05/18/2018 10:37 AM, Abdul Basit wrote:
> It looks a simple question but whats outgoing RTP packets destination?
> Is CALLEE IP present on that NATed destination?
> Confirm that RTP Proxy determined that NATed IPs properly.
> What did you receive in 200OK from CALLEE?
> Check if engaged RTP ports are open in the flow?
>
>
> --
> regards,
>
> abdul basit
>
> On 18 May 2018 at 13:08, Bilal Abbasi <bilaln018 at gmail.com
> <mailto:bilaln018 at gmail.com>> wrote:
>
> Corrigendum:
> We are getting packets from CALLER*
>
> Regards
> Abbasi
>
> On Fri, 18 May 2018 at 12:46 PM, Bilal Abbasi <bilaln018 at gmail.com
> <mailto:bilaln018 at gmail.com>> wrote:
>
> Actually they dont even get out of rtpproxy, we cant see that
> in the in sngrep/tcpdump.
> We are getting packets from callee but nothing going out of
> rtpproxy(talking about local dump)
>
> Regards
> Abbasi
>
> On Fri, May 18, 2018, 12:13 Giovanni Tommasini - evosip
> <giovanni.tommasini at evosip.cloud> wrote:
>
> Hi Younas,
>
> when you have a call if you make a trace in your sip
> serverwith sngrep or tshark can you see the RTP packet ?
> you says "I have kamailio server behind nat with
> rptproxy.", so is it possible that the router in front
> your SIP server blocks the traffic? could you have a trace
> there?
> I mean the packets exit the rtpproxy but don't arrive to
> callee or just don't come out of the rtpproxy?
>
> Giovanni Tommasini | *
>
> evosip* <http://evosip.cloud>
>
>
> 2018-05-18 1:36 GMT+02:00 Aqs Younas <aqsyounas at gmail.com
> <mailto:aqsyounas at gmail.com>>:
>
> Thanks for replying. Callee is actually a sip
> provider. I see no firewall or iptables rules on
> server to prevent rtp following towards callee.
>
> Is there anything i can do to see which thing is
> blocking rtps.
>
> Best
>
> On Fri, 18 May 2018 at 3:59 AM, Mack Hendricks
> <ap at goflyball.com <mailto:ap at goflyball.com>> wrote:
>
> Is there something blocking RTP traffic from
> reaching the callee? Is the callee a carrier or
> the actually endpoint endpoint (aka SIP Phone)?
>
> *Mack Hendricks / Head of Support / dOpenSource*
> web: http://dopensource.com
> support: +888-907-2085
> dSIPRouter <http://dsiprouter.org> - GUI focused
> on implementing Kamailio to provide SIP Trunking
> and PBX Hosting Services
>
>> On May 18, 2018, at 12:50 AM, Aqs Younas
>> <aqsyounas at gmail.com
>> <mailto:aqsyounas at gmail.com>> wrote:
>>
>> Greetings list,
>>
>>
>> I have kamailio server behind nat with rptproxy.
>> But i am getting no voice on the call. After
>> taking trace i could see that rtpproxy was
>> getting rtp packets but not packets was being
>> forwarded towards callee side.
>>
>> Though i see in rtpproxy logs, packets being
>> relayed from caller side.
>>
>> Does rtpproxy wait to receive a single rtp frame
>> from callee before fowarding that to callee?
>>
>> Since, i am getting no rtp from callee. So, might
>> be rptrpoxy is waiting to learn source address of
>> callee side rtp, that is why it is not forwarding
>> rtp packets from caller towards callee.
>>
>>
>> Any pointer/suggestion is much appreciated.
>>
>> Best Regards,
>>
>> Aqs Younas
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180518/66a3c4c2/attachment.html>
More information about the sr-users
mailing list