1 Nov
2013
1 Nov
'13
4:43 p.m.
It works !!
"a" flag in rtpproxy_manage() solve it.
I can see that similar ports are used in flow, but seems like "a" flag
instructs the rtpproxy or kamailio to listen properly.
Thanks a lot team !!
Lucas Girard
On Fri, 2013-11-01 at 15:28 +0100, Daniel-Constantin Mierla wrote:
Hello,
indeed, 'a' flag should be used for asymmetric rtp. However, iirc, in
some cases when one side was symmetric and the other one not, the rtp
didn't flow properly. I had to use fix_contact_sdp() followed by
msg_apply_changes() for the party behind the nat to make it trustable-ip
in sdp. Might have been a special case, though, but could help to look
at different solutions.
Cheers,
Daniel
On 11/1/13 11:35 AM, Daniel Grotti wrote:
Hi,
you can try also to set flag 'a' in on_reply route for that peer:
a - flags that UA from which message is received doesn't support symmetric RTP.
(automatically sets the 'r' flag)
Don't know if it can help, never tested.
As far as I know if rtpproxy receives RTP stream for port X, it will send back the RTP
traffic to the same port X, even if the port is different from the poert negotiated in
SDP.
I've never had a problem like this, the only issue I've got generating an
asymmetric rtp was causes by a router - between rtpproxy and peer - which changed the RTP
port of the peer.
Daniel
On Thursday, October 31, 2013 22:10 CET, Lucas Girard <lgirard(a)commpartner.net>
wrote:
Yes, I have used the r flag, in
rtpproxy_manage(). I have not offer or
answer functions, just manage.
On Thu, 2013-10-31 at 21:41 +0100, Daniel Grotti wrote:
> Hi Lucas,
>
> are you using 'r' flag in rtpproxy_offer/answer ?
> Try to use it.
>
> Daniel
>
>
>
>
>
>
> On Thursday, October 31, 2013 20:56 CET, Lucas Girard <lgirard(a)commpartner.net>
wrote:
>
>> Yes Daniel, you are right.
>> Thats behavior is supposed to be Asymmetric RTP? Because I can not find
>> definitions about which ports should be used.
>>
>>
>> On Thu, 2013-10-31 at 16:18 +0100, Daniel Grotti wrote:
>>
>>> Hi Girard,
>>>
>>> looks like the Provider are sending RTP from port 5392 instead of 5394
>>> as in SDP, rtpproxy send traffic to 5392 as well.
>>>
>>>
>>> Daniel
>>>
>>>
>>>
>>>
>>> On 10/31/2013 04:13 PM, Lucas Girard wrote:
>>>> Hi all,
>>>> I have an issue with a Kamailio and rtpProxy, when Asymmetric RTP is
used.
>>>>
>>>> I have the system running, lines registered in Kamailio are able to call
>>>> to several destinations, but I have a problem with one provider that use
>>>> Asymmetric RTP (others providers use Symmetric RTP and I dont have any
>>>> issues).
>>>>
>>>> A -----> Kamailio & RTPProxy ----------> Trunk ------->
Provider
>>>> (Asymmetric RTP) -------> B
>>>>
>>>> A is calling B.
>>>> The problem is that line in kamailio A can listen to B, but B can not
>>>> listen what A says.
>>>>
>>>> I have captured the sip dialog and rtp traffic and I can see that:
>>>>
>>>> Kamailio tells to provider that is using the port 52388 (media port in
SDP).
>>>> Providers tells Kamailio that is using the port 5394 (media port in
SDP).
>>>> RTP traffic from Providers to kamailio goes from port 5392 to 52388.
>>>> RTP traffic from Kamailio to Provider goes from port 52388 to 5392.
>>>>
>>>>
>>>> I have not found an RFC regarding Asymmetric RTP. The question are,
>>>> why RTP is sent from Kamailio (rtpproxy) to Provider to destination port
>>>> 5392?
>>>> It should use 5394 as SDP indicate?
>>>> or, port 5392 is learned when RTP traffic was received from 5392 to
52388?
>>>>
>>>>
>>>> /# kamailio -V/
>>>> /version: kamailio //*3.3.0 (i386/linux)*/
>>>> /flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
>>>> USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
>>>> PKG_MALLOC, F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
>>>> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES/
>>>> /ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB/
>>>> /poll method support: poll, epoll_lt, epoll_et, sigio_rt, select./
>>>> /id: unknown/
>>>> /compiled on 22:17:07 Jun 18 2012 with gcc 4.4.5/
>>>>
>>>> /# rtpproxy -v/
>>>> */Basic version: 20040107/*
>>>> /Extension 20050322: Support for multiple RTP streams and MOH/
>>>> /Extension 20060704: Support for extra parameter in the V command/
>>>> /Extension 20071116: Support for RTP re-packetization/
>>>> /Extension 20071218: Support for forking (copying) RTP stream/
>>>> /Extension 20080403: Support for RTP statistics querying/
>>>> /Extension 20081102: Support for setting codecs in the update/lookup
>>>> command/
>>>> /Extension 20081224: Support for session timeout notifications/
>>>>
>>>>
>>>> I hope to be clear with this explanation.
>>>>
>>>> Regards,
>>>>
>>>> Lucas Girard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users