Hum, ok, quite bad news. Any idea on how I can make a quick & dirty patch to have this work ? <br><br>Or maybe you know a way to have a kind of RTP proxy __software__ which doesn't rely on NAT or IP routing.<br><br>
my goal is to have, for any video call a well defined path for RTP flow, which can be :<br>- Client A --> "RTP proxy 1" --> "RTP proxy 2" --> "RTP proxy N" --> client B<br>with "RTP proxy" 1, 2, 3, ... in the same LAN segment (in fact not really but it's the best and easiest way to explain our objectives)<br>
<br>OpenSIPs + rtpproxy doesn't work very well (can't pass through multiple proxy :s)<br><br>Thanks<br><br><br><div class="gmail_quote">2010/9/2 Kevin P. Fleming <span dir="ltr"><<a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On 09/02/2010 07:09 AM, Nicolas Bourbaki wrote:<br>
<br>
> I've got a litlle problem : Asterisk rewrite every SDP in codec<br>
> negociation, even for video. I would have liked that I don't loose any<br>
> information for video, as some are constructor specific.<br>
<br>
</div>Asterisk does not 'rewrite' SDP; it's not a proxy. Asterisk is a B2BUA,<br>
and as such when it creates an outbound channel, that channel is totally<br>
distinct from (but related to) the inbound channel. The SDP on the<br>
outbound channel is created by Asterisk based on the configuration of<br>
the SIP endpoint that is being called, with a little bit of input from<br>
the incoming channel's configuration.<br>
<br>
The issue you are trying to address has been known for quite a while,<br>
and there was a 'videocaps' branch/patch for Asterisk 1.4 that addressed<br>
it in a fairly simple way for video streams specifically. There have<br>
been many discussions about how to do this the right way, and those are<br>
still ongoing. Whatever solution is created is not going to involve<br>
directly copying SDP information from one channel to another, because<br>
that doesn't support Asterisk's nature as a multiprotocol telephony<br>
platform.<br>
<br>
--<br>
Kevin P. Fleming<br>
Digium, Inc. | Director of Software Technologies<br>
<div class="im">445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
</div>skype: kpfleming | jabber: <a href="mailto:kfleming@digium.com">kfleming@digium.com</a><br>
Check us out at <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<div class="im"><br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
</div>asterisk-dev mailing list<br>
<div class="im">To UNSUBSCRIBE or update options visit:<br>
</div> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</blockquote></div><br>