[OpenSIPS-Users] RTP and RTCP

David Villasmil david.villasmil.work at gmail.com
Sun Aug 10 22:32:05 CEST 2008 

Hello Flavio! Long time! jeje.


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?

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.
Thanks!

David

On Sat, Aug 9, 2008 at 9:09 PM, Flavio Goncalves
<flavio at asteriskguide.com>wrote:

> Hi David,
>
> 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 *Supported* header, you should
> have "timers" indicating the support of the RFC4028).
>
> 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.
>
> 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?
>
> Flavio E. Goncalves
>
>
>
>
> ----- Mensagem original ----
> De: David Villasmil <david.villasmil.work at gmail.com>
> Para: David Villasmil <david.villasmil.work at gmail.com>
> Cc: users at lists.opensips.org
> Enviadas: Sábado, 9 de Agosto de 2008 13:54:20
> Assunto: Re: [OpenSIPS-Users] RTP and RTCP
>
>  Previous email had a typo:
>
> So something like this SHOULD do the trick?
>
> v=0
> o=alice 2890844526 2890844526 IN IP4 user.address.com  <------ USERS IP
> FOR RTP
> s=
> c=IN IP4 user.address.com
> t=0 0
> m=audio 49170 RTP/AVP 0 8 97
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:97 iLBC/8000
> m=video 51372 RTP/AVP 31 32
> a=rtpmap:31 H261/90000
> a=rtpmap:32 MPV/90000
> m=audio 49170 RTP/AVP 0
> a=rtcp:53020 IN IP4 rtp-proxy.address.com          <---- OUR RTP PROXT
>
> If the UAC is rfc compliant, then rtps would flow directly from UAC to UAC,
> *BUT* RTCP would go via our rtpproxy/mediaproxy.
>
> 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???
>
> we need an rtp expert here...
>
>
> ;-)
>
> David
>
>
>
>>
>>
>> On Sat, Aug 9, 2008 at 6:38 PM, David Villasmil <
>> david.villasmil.work at gmail.com> wrote:
>>
>>> 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?
>>>
>>>
>>> On Sat, Aug 9, 2008 at 2:52 PM, Ovidiu Sas <osas at voipembedded.com>wrote:
>>>
>>>> You will need full support from the client and I doubt that there are
>>>> implementation that are doing this.
>>>>
>>>> see http://www.ietf.org/rfc/rfc3605.txt:
>>>>
>>>> 2.1.  The RTCP Attribute
>>>>
>>>>   The RTCP attribute is used to document the RTCP port used for media
>>>>   stream, when that port is not the next higher (odd) port number
>>>>   following the RTP port described in the media line.  The RTCP
>>>>   attribute is a "value" attribute, and follows the general syntax
>>>>   specified page 18 of [RFC2327]: "a=<attribute>:<value>".  For the
>>>>   RTCP attribute:
>>>>
>>>>   *  the name is the ascii string "rtcp" (lower case),
>>>>
>>>>   *  the value is the RTCP port number and optional address.
>>>>
>>>>   The formal description of the attribute is defined by the following
>>>>   ABNF [RFC2234] syntax:
>>>>
>>>>   rtcp-attribute =  "a=rtcp:" port  [nettype space addrtype space
>>>>                         connection-address] CRLF
>>>>
>>>>   In this description, the "port", "nettype", "addrtype" and
>>>>   "connection-address" tokens are defined as specified in "Appendix A:
>>>>   SDP Grammar" of [RFC2327].
>>>>
>>>>   Example encodings could be:
>>>>
>>>>    m=audio 49170 RTP/AVP 0
>>>>    a=rtcp:53020
>>>>
>>>>    m=audio 49170 RTP/AVP 0
>>>>    a=rtcp:53020 IN IP4 126.16.64.4
>>>>
>>>>    m=audio 49170 RTP/AVP 0
>>>>    a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD
>>>>
>>>>
>>>> Regards,
>>>> Ovidiu Sas
>>>>
>>>> On Sat, Aug 9, 2008 at 8:16 AM, David Villasmil
>>>> <david.villasmil.work at gmail.com> wrote:
>>>> > Yeah, that's exactly what I don't want. The idea is not to proxy
>>>> media, let
>>>> > media flow between the UACs, but proxy the RTCP...
>>>> >
>>>> >
>>>> > thanks
>>>> >
>>>> > On Sat, Aug 9, 2008 at 2:12 PM, Adam Linford <
>>>> adam.linford at oralnet.co.uk>
>>>> > wrote:
>>>> >>
>>>> >> rtcp is sent to the exact same destination as the RTP, afaik, so if
>>>> you
>>>> >> proxy media in your calls, you could get ahold of those packets.
>>>> >>
>>>> >> Cheers,
>>>> >> Adam
>>>> >>
>>>> >> On 9 Aug 2008, at 12:46, David Villasmil wrote:
>>>> >>
>>>> >>> Got an easy question:
>>>> >>>
>>>> >>>     RTCP packet are send to monitor media QoS, this much I know. ;)
>>>> My
>>>> >>> question is this: Are RTCP packets sent directly between end points?
>>>> Or can
>>>> >>> they be routed using a thrid party? For instance, Lets say 1 UAC
>>>> makes a
>>>> >>> call through SIP Server A, and UAC 2 ansers the call, RTP packets
>>>> are sent
>>>> >>> from UAC <--> UAC directly, but can they be instructed to send RTCP
>>>> packets
>>>> >>> via SIP Server A? I obviously haven't read the RFC, but if this
>>>> could be
>>>> >>> done, we would have a way of knowing whether the call is still up or
>>>> not,
>>>> >>> hence perfect accounting even if we don't receive the BYE from the
>>>> UACs.
>>>> >>>
>>>> >>> thanks
>>>> >>>
>>>> >>>
>>>> >>> david
>>>> >>> _______________________________________________
>>>> >>> Users mailing list
>>>> >>> Users at lists.opensips.org
>>>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Users mailing list
>>>> > Users at lists.opensips.org
>>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20080810/7ab131d3/attachment.htm

More information about the Users mailing list