[OpenSIPS-Users] RTP and RTCP

[David Villasmil]

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/20080809/5cf17a8e/attachment-0001.htm