[OpenSIPS-Users] RTP and RTCP

[David Villasmil]

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 host.atlanta.example.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/20080809/5e4cc546/attachment.htm