Hi,
I'm using kamailio from latest git-HEAD. The rtpproxy i'm using also from latest git.
Our network topology is following :
sip-softphone--------->kamailio/rtpproxy-------->softswitch---->gateway
Because of saving bandwidth we need to use the "re-packetization" feature of rtpproxy.
When we don't use it, it works perfectly without any glitches.
Now if we use the repacketization feature like following :
if (is_request()) { rtpproxy_manage("co"); } if (is_reply()) { rtpproxy_manage("z80"); }
Then a bizzare thing happens. Suddenly rtp packets from gateway stops coming. So we don't have any voice in softphone, although everything seems ok at the "mobile phone's end."
This is bizzare at multiple levels, as you can see we are using repacketize feature to increase the payload size from "proxy to softphone" leg. So we actually don't touch the packets from "softphone to proxy" leg. So how the gateway predicts this and decides not to send packets is beyond my understanding.
As far as i can understand, rtpproxy_manage() is doing something to SDP which makes it impossible to send packets through the proxy.
I will provide further information if anybody wants to look at it.
Thanks in advance.
Hello,
you should provide a ngrep output of such call (incoming invite to the forwarded ack for 200ok), we can check the sdp.
On the other hand, I didn't have good experiences with rtpproxy application from git head, can you try with 1.2.1?
Cheers, Daniel
On 07/05/14 08:34, aft wrote:
Hi,
I'm using kamailio from latest git-HEAD. The rtpproxy i'm using also from latest git.
Our network topology is following :
sip-softphone--------->kamailio/rtpproxy-------->softswitch---->gateway
Because of saving bandwidth we need to use the "re-packetization" feature of rtpproxy.
When we don't use it, it works perfectly without any glitches.
Now if we use the repacketization feature like following :
if (is_request()) { rtpproxy_manage("co"); } if (is_reply()) { rtpproxy_manage("z80"); }
Then a bizzare thing happens. Suddenly rtp packets from gateway stops coming. So we don't have any voice in softphone, although everything seems ok at the "mobile phone's end."
This is bizzare at multiple levels, as you can see we are using repacketize feature to increase the payload size from "proxy to softphone" leg. So we actually don't touch the packets from "softphone to proxy" leg. So how the gateway predicts this and decides not to send packets is beyond my understanding.
As far as i can understand, rtpproxy_manage() is doing something to SDP which makes it impossible to send packets through the proxy.
I will provide further information if anybody wants to look at it.
Thanks in advance.
On Wed, May 7, 2014 at 2:50 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you should provide a ngrep output of such call (incoming invite to the forwarded ack for 200ok), we can check the sdp.
I will capture such a call and post it as soon as possible
On the other hand, I didn't have good experiences with rtpproxy application from git head, can you try with 1.2.1?
Well the same thing happens with 1.2.1 also. Reasons for using the git-head is to see whether the problem went away.
Cheers, Daniel
On 07/05/14 08:34, aft wrote:
Hi,
I'm using kamailio from latest git-HEAD. The rtpproxy i'm using also from latest git.
Our network topology is following :
sip-softphone--------->kamailio/rtpproxy-------->softswitch---->gateway
Because of saving bandwidth we need to use the "re-packetization" feature of rtpproxy.
When we don't use it, it works perfectly without any glitches.
Now if we use the repacketization feature like following :
if (is_request()) { rtpproxy_manage("co"); } if (is_reply()) { rtpproxy_manage("z80"); }
Then a bizzare thing happens. Suddenly rtp packets from gateway stops coming. So we don't have any voice in softphone, although everything seems ok at the "mobile phone's end."
This is bizzare at multiple levels, as you can see we are using repacketize feature to increase the payload size from "proxy to softphone" leg. So we actually don't touch the packets from "softphone to proxy" leg. So how the gateway predicts this and decides not to send packets is beyond my understanding.
As far as i can understand, rtpproxy_manage() is doing something to SDP which makes it impossible to send packets through the proxy.
I will provide further information if anybody wants to look at it.
Thanks in advance.
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Wed, May 7, 2014 at 3:17 PM, aft aftnix@gmail.com wrote:
On Wed, May 7, 2014 at 2:50 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you should provide a ngrep output of such call (incoming invite to the forwarded ack for 200ok), we can check the sdp.
[1] This is the capture made at the softphone's end : http://pastebin.com/Lda0FYjp
This is the capture made at the proxy's end :
[2] Another thing is this does not happen everytime. It happens like 50% of the time.
[3] If i don't do any repacketization, then 100% calls succeeds without any problem. This problem comes up only when the "repacketization" feature is turned on.
[4] Conceptually its bizarre, because if turn on the "repacketization" at the proxy, how the switch/gateway knows at advance that there is going to be repacketization at the proxy's end? So my suspicision is that when instructing rtpproxy to do repacketization, kamailio is doing something wrong in SDP so that the rtp packets are not flowing through the proxy server. At first look, SDP's looked OK to me though.
I will capture such a call and post it as soon as possible
On the other hand, I didn't have good experiences with rtpproxy application from git head, can you try with 1.2.1?
Well the same thing happens with 1.2.1 also. Reasons for using the git-head is to see whether the problem went away.
Cheers, Daniel
On 07/05/14 08:34, aft wrote:
Hi,
I'm using kamailio from latest git-HEAD. The rtpproxy i'm using also from latest git.
Our network topology is following :
sip-softphone--------->kamailio/rtpproxy-------->softswitch---->gateway
Because of saving bandwidth we need to use the "re-packetization" feature of rtpproxy.
When we don't use it, it works perfectly without any glitches.
Now if we use the repacketization feature like following :
if (is_request()) { rtpproxy_manage("co"); } if (is_reply()) { rtpproxy_manage("z80"); }
Then a bizzare thing happens. Suddenly rtp packets from gateway stops coming. So we don't have any voice in softphone, although everything seems ok at the "mobile phone's end."
This is bizzare at multiple levels, as you can see we are using repacketize feature to increase the payload size from "proxy to softphone" leg. So we actually don't touch the packets from "softphone to proxy" leg. So how the gateway predicts this and decides not to send packets is beyond my understanding.
As far as i can understand, rtpproxy_manage() is doing something to SDP which makes it impossible to send packets through the proxy.
I will provide further information if anybody wants to look at it.
Thanks in advance.
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- -Cheers -Arif
The sdp itself is well formatted, but for repacketization I think there should be a new attribute:
a=ptime:NNN
Can you compare the sdp from a case when audio works ok agaist when it is one way audio?
Also, you can look at rtp traffic -- rtpproxy can be started with min and max port to use for rtp, then in ngrep you can use portrange to watch the traffic on these ports. See if the rtp packets come to rtpproxy and where they are sent.
Cheers, Daniel
On 08/05/14 13:25, aft wrote:
On Wed, May 7, 2014 at 3:17 PM, aft aftnix@gmail.com wrote:
On Wed, May 7, 2014 at 2:50 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you should provide a ngrep output of such call (incoming invite to the forwarded ack for 200ok), we can check the sdp.
[1] This is the capture made at the softphone's end : http://pastebin.com/Lda0FYjp
This is the capture made at the proxy's end :
[2] Another thing is this does not happen everytime. It happens like 50% of the time.
[3] If i don't do any repacketization, then 100% calls succeeds without any problem. This problem comes up only when the "repacketization" feature is turned on.
[4] Conceptually its bizarre, because if turn on the "repacketization" at the proxy, how the switch/gateway knows at advance that there is going to be repacketization at the proxy's end? So my suspicision is that when instructing rtpproxy to do repacketization, kamailio is doing something wrong in SDP so that the rtp packets are not flowing through the proxy server. At first look, SDP's looked OK to me though.
I will capture such a call and post it as soon as possible
On the other hand, I didn't have good experiences with rtpproxy application from git head, can you try with 1.2.1?
Well the same thing happens with 1.2.1 also. Reasons for using the git-head is to see whether the problem went away.
Cheers, Daniel
On 07/05/14 08:34, aft wrote:
Hi,
I'm using kamailio from latest git-HEAD. The rtpproxy i'm using also from latest git.
Our network topology is following :
sip-softphone--------->kamailio/rtpproxy-------->softswitch---->gateway
Because of saving bandwidth we need to use the "re-packetization" feature of rtpproxy.
When we don't use it, it works perfectly without any glitches.
Now if we use the repacketization feature like following :
if (is_request()) { rtpproxy_manage("co"); } if (is_reply()) { rtpproxy_manage("z80"); }
Then a bizzare thing happens. Suddenly rtp packets from gateway stops coming. So we don't have any voice in softphone, although everything seems ok at the "mobile phone's end."
This is bizzare at multiple levels, as you can see we are using repacketize feature to increase the payload size from "proxy to softphone" leg. So we actually don't touch the packets from "softphone to proxy" leg. So how the gateway predicts this and decides not to send packets is beyond my understanding.
As far as i can understand, rtpproxy_manage() is doing something to SDP which makes it impossible to send packets through the proxy.
I will provide further information if anybody wants to look at it.
Thanks in advance.
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- -Cheers -Arif
On Mon, May 12, 2014 at 1:54 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
The sdp itself is well formatted, but for repacketization I think there should be a new attribute:
a=ptime:NNN
How can i add this attribute to the SDP from kamailio? Options for rtpproxy_offer() and rtpproxy_answer() does have something like that.
Can you compare the sdp from a case when audio works ok agaist when it is one way audio?
I will certainly do that and post the results.
Also, you can look at rtp traffic -- rtpproxy can be started with min and max port to use for rtp, then in ngrep you can use portrange to watch the traffic on these ports. See if the rtp packets come to rtpproxy and where they are sent.
I have done some new testing and posted a mail with those results. It was a mistake by me to say "packets" are not coming from gateway.
Actually packets come from gateway fine at the rtpproxy box. But these packets are not relayed to the caller. See my new mail for details.
Cheers, Daniel
On 08/05/14 13:25, aft wrote:
On Wed, May 7, 2014 at 3:17 PM, aft aftnix@gmail.com wrote:
On Wed, May 7, 2014 at 2:50 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you should provide a ngrep output of such call (incoming invite to the forwarded ack for 200ok), we can check the sdp.
[1] This is the capture made at the softphone's end : http://pastebin.com/Lda0FYjp
This is the capture made at the proxy's end :
[2] Another thing is this does not happen everytime. It happens like 50% of the time.
[3] If i don't do any repacketization, then 100% calls succeeds without any problem. This problem comes up only when the "repacketization" feature is turned on.
[4] Conceptually its bizarre, because if turn on the "repacketization" at the proxy, how the switch/gateway knows at advance that there is going to be repacketization at the proxy's end? So my suspicision is that when instructing rtpproxy to do repacketization, kamailio is doing something wrong in SDP so that the rtp packets are not flowing through the proxy server. At first look, SDP's looked OK to me though.
I will capture such a call and post it as soon as possible
On the other hand, I didn't have good experiences with rtpproxy application from git head, can you try with 1.2.1?
Well the same thing happens with 1.2.1 also. Reasons for using the git-head is to see whether the problem went away.
Cheers, Daniel
On 07/05/14 08:34, aft wrote:
Hi,
I'm using kamailio from latest git-HEAD. The rtpproxy i'm using also from latest git.
Our network topology is following :
sip-softphone--------->kamailio/rtpproxy-------->softswitch---->gateway
Because of saving bandwidth we need to use the "re-packetization" feature of rtpproxy.
When we don't use it, it works perfectly without any glitches.
Now if we use the repacketization feature like following :
if (is_request()) { rtpproxy_manage("co"); } if (is_reply()) { rtpproxy_manage("z80"); }
Then a bizzare thing happens. Suddenly rtp packets from gateway stops coming. So we don't have any voice in softphone, although everything seems ok at the "mobile phone's end."
This is bizzare at multiple levels, as you can see we are using repacketize feature to increase the payload size from "proxy to softphone" leg. So we actually don't touch the packets from "softphone to proxy" leg. So how the gateway predicts this and decides not to send packets is beyond my understanding.
As far as i can understand, rtpproxy_manage() is doing something to SDP which makes it impossible to send packets through the proxy.
I will provide further information if anybody wants to look at it.
Thanks in advance.
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- -Cheers -Arif
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-
aft -
Daniel-Constantin Mierla