Hello,

 

I have seen that the problem can occur due to the kernel limitation.

So, I have changed the local_port range to be sure that they include the port range of RTPProxy.

 

But, I still not explain this limitation. Because, even with the kernel limitation, they should be have sufficient number of ports to allocate.

 

Any idea? Thanks.


Regards,

 

Igor.

 

De : Igor Potjevlesch [mailto:igor.potjevlesch@gmail.com]
Envoyé : lundi 27 octobre 2014 12:21
À : sr-users@lists.sip-router.org
Objet : RE: rtpproxy_manage fails to rewrite SDP

 

Hello,

 

In addition: the behaviour looks to occur when there is many calls to be treated.

Looking at /var/log/messages, I can see thousand of this message:

incorrect port 0 in reply from rtp proxy

 

At this time, where the flow is more low, no more errors and every calls are properly rewritten.

 

Regards,

 

Igor.

 

De : Igor Potjevlesch [mailto:igor.potjevlesch@gmail.com]
Envoyé : lundi 27 octobre 2014 11:47
À :
sr-users@lists.sip-router.org
Objet : rtpproxy_manage fails to rewrite SDP

 

Hello,

 

I’m working with rtpproxy module for managing calls to a particular route.

The thing is that for some calls, the “Connection information” is not rewritten properly whereas another calls, less than 1 second before or after, are properly rewritten.

 

When “cr_route” defines that the call must be route to this carrier, I go to a route in order to make some change:

-          Keep only PCMA, PCMU, G729a and telephone-event

-          Depends on the R-URI:

o   If the uri contains IP addresses or domain name of the carrier: rtpproxy_manage("iefrcoz20","<CARRIER_IP_ADDRESS");

o   else : rtpproxy_manage("eifrcoz20");

 

Kamailio listens on <CARRIER_IP_ADDRESS> and also on an internal one.

A dedicated instance of RTPProxy runs with the following option: “-l <INTERNAL_IP_ADDRESS>/<CARRIER_IP_ADDRESS>”.

 

The idea is to tell to my customers to send their RTP to the internal IP address, and to tell to the carrier to send the RTP to the IP address that they have attributed to me.

 

For hundred and hundred calls, this mechanism is working fine. But sometimes, no, the SDP remains as the original one.

 

I don’t know how to diagnose this. Could it be a saturation of RTPProxy?

 

Regards,

 

Igor.