<div dir="ltr"><div class="Ih2E3d"><p>Hello Flavio! Long time! jeje.</p>
</div><p><br></p><div class="Ih2E3d">I don't see any, no. So "in
principle" It CAN be done, provided rtpproxy's developers extend that
functionality? Another question is, would DIALOG module need to be
modified for this? Or is there already some mechanism to tear down the
call when receiving a signal from the rtpproxy?</div>
<p>Maybe getting rtpproxy to do this extension would be difficult for
me. On the other hand, if anyone here has any contact with him, I'm
sure he/they will be in a position of understanding the (very) big
implications of getting this to work, as much of rtp media flow would
not have to be via rtpproxy and there would still be accurate billing.
The cost-savings benefits will be enormous for us all.</p>
Thanks!<br><br>David<br><br><div class="gmail_quote">On Sat, Aug 9, 2008 at 9:09 PM, Flavio Goncalves <span dir="ltr"><<a href="mailto:flavio@asteriskguide.com">flavio@asteriskguide.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><div>Hi David, </div>
<div> </div>
<div>Let me put some ideas. You could use SIP Session Timers for this. Only one side of the call needs to support it, so you could provision the clients (softphones and ATAs) with SST enabled minimizing the problem. The problem with this approach is that eventually we wouldn't have SST support from some clients and/or gateways/wholesale providers. However, you can identify clients without SST support (In the <b>Supported</b> header, you should have "timers" indicating the support of the RFC4028). </div>
<div> </div>
<div>With this header you could discover if the UAC or the UAS support SST. So, it would be possible to handle only the remaining clients (a lot more scalable, since several clients and gateways support SST). My suggestion is to send the remaining clients to RTPPRoxy and convince the developer (RTPPROXY, NATHELPER) to extend the funcionality of RTPProxy to end the dialog using the DIALOG module from inside the NATHELPER module if RTPProxy detects a timeout in the RTP. </div>
<div> </div>
<div>With this solution we could have a migration path from solutions based in RTP timeout to solutions based on SIP timeout using RFC standards. Have you seen any misconception in the approach suggested?</div>
<div> </div>
<div>Flavio E. Goncalves</div>
<div> </div>
<div><br> </div>
<div style="font-size: 10pt; font-family: arial,helvetica,sans-serif;"><br>
<div style="font-size: 12pt; font-family: times new roman,new york,times,serif;">----- Mensagem original ----<br>De: David Villasmil <<a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a>><br>
Para: David Villasmil <<a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a>><br>Cc: <a href="mailto:users@lists.opensips.org" target="_blank">users@lists.opensips.org</a><br>
Enviadas: Sábado, 9 de Agosto de 2008 13:54:20<br>Assunto: Re: [OpenSIPS-Users] RTP and RTCP<br><br>
<div dir="ltr">
<div class="gmail_quote">
<div>Previous email had a typo:<br><br>So something like this SHOULD do the trick?<br><br>v=0<br>o=alice 2890844526 2890844526 IN IP4 <a href="http://user.address.com/" rel="nofollow" target="_blank">user.address.com</a> <------ USERS IP FOR RTP<br>
s=<br>c=IN IP4 <a href="http://user.address.com/" rel="nofollow" target="_blank">user.address.com</a><br>t=0 0<br>m=audio 49170 RTP/AVP 0 8 97<br>a=rtpmap:0 PCMU/8000<br>a=rtpmap:8 PCMA/8000<br>a=rtpmap:97 iLBC/8000<br>m=video 51372 RTP/AVP 31 32<br>
a=rtpmap:31 H261/90000<br>a=rtpmap:32 MPV/90000
<div><br>m=audio 49170 RTP/AVP 0<br></div>a=rtcp:53020 IN IP4 <a href="http://rtp-proxy.address.com/" rel="nofollow" target="_blank">rtp-proxy.address.com</a> <---- OUR RTP PROXT<br><br>If the UAC is rfc compliant, then rtps would flow directly from UAC to UAC, *BUT* RTCP would go via our rtpproxy/mediaproxy.<br>
<br>If this does work this way, we can -at least in principle- do accurate accounting without having to be in the middle or rtps flow! Can you imagine the cost-savings this would entitle???<br><br>we need an rtp expert here... <br>
<br><br>;-)<br><br>David<br><br> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">
<div>
<div><br><br>
<div class="gmail_quote">On Sat, Aug 9, 2008 at 6:38 PM, David Villasmil <span dir="ltr"><<a href="mailto:david.villasmil.work@gmail.com" rel="nofollow" target="_blank">david.villasmil.work@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">So if I understand this completely, when the proxy sends the SDP, if our proxy (openSIPS) sends our mediaproxy/rtpproxy IP/PORT but the endpoint's IP/PORT, media goes directly to the UAC but RTCP goes via out mediaproxy/rtpproxy... if the UAC if rfc3605 compliant?
<div>
<div></div>
<div><br><br>
<div class="gmail_quote">On Sat, Aug 9, 2008 at 2:52 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com" rel="nofollow" target="_blank">osas@voipembedded.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You will need full support from the client and I doubt that there are<br>implementation that are doing this.<br>
<br>see <a href="http://www.ietf.org/rfc/rfc3605.txt" rel="nofollow" target="_blank">http://www.ietf.org/rfc/rfc3605.txt</a>:<br><br>2.1. The RTCP Attribute<br><br> The RTCP attribute is used to document the RTCP port used for media<br>
stream, when that port is not the next higher (odd) port number<br> following the RTP port described in the media line. The RTCP<br> attribute is a "value" attribute, and follows the general syntax<br> specified page 18 of [RFC2327]: "a=<attribute>:<value>". For the<br>
RTCP attribute:<br><br> * the name is the ascii string "rtcp" (lower case),<br><br> * the value is the RTCP port number and optional
address.<br><br> The formal description of the attribute is defined by the following<br> ABNF [RFC2234] syntax:<br><br> rtcp-attribute = "a=rtcp:" port [nettype space addrtype space<br> connection-address] CRLF<br>
<br> In this description, the "port", "nettype", "addrtype" and<br> "connection-address" tokens are defined as specified in "Appendix A:<br> SDP Grammar" of [RFC2327].<br>
<br> Example encodings could be:<br><br> m=audio 49170 RTP/AVP 0<br> a=rtcp:53020<br><br> m=audio 49170 RTP/AVP 0<br> a=rtcp:53020 IN IP4 <a href="http://126.16.64.4/" rel="nofollow" target="_blank">126.16.64.4</a><br>
<br> m=audio 49170 RTP/AVP 0<br> a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD<br><br><br>Regards,<br><font color="#888888">Ovidiu Sas<br></font>
<div>
<div></div>
<div><br>On Sat, Aug 9, 2008 at 8:16 AM, David Villasmil<br><<a href="mailto:david.villasmil.work@gmail.com" rel="nofollow" target="_blank">david.villasmil.work@gmail.com</a>> wrote:<br>> Yeah, that's exactly what I don't want. The idea is not to proxy media, let<br>
> media flow between the UACs, but proxy the RTCP...<br>><br>><br>> thanks<br>><br>> On Sat, Aug 9, 2008 at 2:12 PM, Adam Linford <<a href="mailto:adam.linford@oralnet.co.uk" rel="nofollow" target="_blank">adam.linford@oralnet.co.uk</a>><br>
> wrote:<br>>><br>>> rtcp is sent to the exact same destination as the RTP, afaik, so if you<br>>> proxy media in your calls, you could get ahold of those packets.<br>>><br>>> Cheers,<br>>> Adam<br>
>><br>>> On 9 Aug 2008, at 12:46, David Villasmil wrote:<br>>><br>>>> Got an
easy question:<br>>>><br>>>> RTCP packet are send to monitor media QoS, this much I know. ;) My<br>>>> question is this: Are RTCP packets sent directly between end points? Or can<br>>>> they be routed using a thrid party? For instance, Lets say 1 UAC makes a<br>
>>> call through SIP Server A, and UAC 2 ansers the call, RTP packets are sent<br>>>> from UAC <--> UAC directly, but can they be instructed to send RTCP packets<br>>>> via SIP Server A? I obviously haven't read the RFC, but if this could be<br>
>>> done, we would have a way of knowing whether the call is still up or not,<br>>>> hence perfect accounting even if we don't receive the BYE from the UACs.<br>>>><br>>>> thanks<br>
>>><br>>>><br>>>> david<br>>>> _______________________________________________<br>>>> Users mailing
list<br>>>> <a href="mailto:Users@lists.opensips.org" rel="nofollow" target="_blank">Users@lists.opensips.org</a><br>>>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="nofollow" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>><br>><br>><br>> _______________________________________________<br>> Users mailing list<br>> <a href="mailto:Users@lists.opensips.org" rel="nofollow" target="_blank">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="nofollow" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>><br>><br></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></div></div></blockquote></div><br></div>