<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The sdp itself is well formatted, but for repacketization I think
there should be a new attribute:<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<pre class="newpage">a=ptime:NNN</pre>
Can you compare the sdp from a case when audio works ok agaist when
it is one way audio?<br>
<br>
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.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 08/05/14 13:25, aft wrote:<br>
</div>
<blockquote
cite="mid:CAGuaRCtWC-zQ-2TD7iSrHyZDAksFpwiMKGtT+_d-ktbkqs-91w@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, May 7, 2014 at 3:17 PM, aft <a class="moz-txt-link-rfc2396E" href="mailto:aftnix@gmail.com"><aftnix@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, May 7, 2014 at 2:50 PM, Daniel-Constantin Mierla
<a class="moz-txt-link-rfc2396E" href="mailto:miconda@gmail.com"><miconda@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
you should provide a ngrep output of such call (incoming invite to the
forwarded ack for 200ok), we can check the sdp.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
[1] This is the capture made at the softphone's end :
<a class="moz-txt-link-freetext" href="http://pastebin.com/Lda0FYjp">http://pastebin.com/Lda0FYjp</a>
This is the capture made at the proxy's end :
<a class="moz-txt-link-freetext" href="http://pastebin.com/g53pMGAF">http://pastebin.com/g53pMGAF</a>
[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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
I will capture such a call and post it as soon as possible
</pre>
<blockquote type="cite">
<pre wrap="">On the other hand, I didn't have good experiences with rtpproxy application
from git head, can you try with 1.2.1?
</pre>
</blockquote>
<pre wrap="">
Well the same thing happens with 1.2.1 also. Reasons for using the
git-head is to see whether the problem went away.
</pre>
<blockquote type="cite">
<pre wrap="">
Cheers,
Daniel
On 07/05/14 08:34, aft wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
--
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre wrap="">
--
-Cheers
-Arif
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a></pre>
</body>
</html>