Re: [RAI] Using media stream signaling in media plane or in signaling plane (re-send)

[Paul Kyzivat <[e-mail]>]

Bo,

Did you consider the implications if there is more than one stream to be 
paused? (E.g. it's an audio+video call.)

Presumably that would double the message traffic when done in the media 
streams, but not when done in sip. (But the absolute delays may be no 
different.)

	Thanks,
	Paul

On 7/23/12 9:10 AM, Bo Burman wrote:
> As part of the comments during IETF 83 on the following drafts
> * Media Stream Selection
> (_https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection/_)
> * PAUSE / RESUME
> (_https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/_)
> * Codec Operation Point
> (_https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/_)
> there was a discussion on the reasons to use one technology or the other
> for signaling related to specific media streams. The community was
> lacking knowledge of the performance implications coming from
> transporting information using a specific technology, and wanted a
> discussion on this mailing list.
> I want to provide input to this discussion and have performed a
> comparison between using RTCP and using SIP as signaling technology for
> a particular purpose. I chose, more or less arbitrarily, this purpose to
> be sending a "PAUSE" command from a media receiver to a media sender for
> a specific RTP media stream (identified by SSRC).
> Very briefly, these are the results (extracts from Section 5.1 of PAUSE
> / RESUME draft above, where more detailed descriptions of pre-conditions
> and assumptions can be found):
> The targeted topology is outlined in the following figure.
> Provider A's network . Provider B's network
> .
> +-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+
> |Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy|
> +-----+ +------+ +-------+ . +-------+ +-----+
> ^ ^ . ^
> | | SIP/H.248 . |
> | v . |
> SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP |
> | | MCU |<---->| BGW A |<--.-->| BGW B | |
> | +-----+ +-------+ . +-------+ |
> v ^ . ^ v
> +------+ / RTCP . \ RTCP +------+
> | UA A |<---+ . +------>| UA B |
> +------+ . +------+
> In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS
> is an Application Server, MCU is a Multipoint Conference Unit, SGW a
> Signaling GateWay, and BGW a media Border GateWay.
> ...
> As a partial result, the message sizes can be compared, based on the
> messages defined in this specification (Section 8) and a SIP UPDATE
> with contents (Section 10) as discussed above. Favorable and
> unfavorable message sizes are presented as stacked bars in the figure
> below. Message sizes include IPv4 headers but no lower layer data,
> are rounded to the nearest 25 bytes, and the bars are to scale.
> 250 500 750 1000 1250 1500 [byte]
> +---------+---------+---------+---------+---------+---------+--> Size
> |
> +-+--+
> | |50| 125 RTCP
> +-+--+---------------+--------------------------------------------+
> | SIP | 525 1650 |
> +--------------------+--------------------------------------------+
> |
> ...
> Favorable RTCP size comes from using non-compound RTCP packets.
> Favorable SIP size comes from using dynamic SIP SigComp.
> ...
> The signaling delay results of the study are summarized in the
> following two figures. Favorable and unfavorable values are
> presented as stacked bars. Since there are many factors that impact
> the calculations, including some random processes, there are
> uncertainty in the calculations and delay values are thus rounded to
> nearest 5 ms. The bars are to scale.
> 50 100 150 200 250 300 [ms]
> +---------+---------+---------+---------+---------+---------+---> t
> |
> | Wireless UA to Wireless UA
> +---------------------+--------------------------------------+
> | SIP | 110 | 305
> +-----+---------------+-----------------------------+--------+
> |RTCP | 30 | 260
> +-----+---------------------------------------------+
> |
> | Wireless UA to MCU
> +-------------+--+
> | SIP |70| 85
> +----+--------+--+--------------------------+
> |RTCP| 25 | 225
> +----+--------------------------------------+
> |
> | MCU to Wireless UA
> +--------------+-----------------------------------+
> | SIP | 75 | 255
> +---+----------+------------------------------+----+
> | | 20 RTCP | 230
> +---+-----------------------------------------+
> |
> ...
> It should be noted that RTCP scheduling above is based on a 200 kbps
> media stream, leaving only 10 kbps (5%) for RTCP traffic, even for the
> favorable case. Should the media stream instead be 1000 kbps (50 kbps
> RTCP), the unfavorable RTCP delays will be reduced from 260 ms to 115 ms
> for Wireless-Wireless, from 225 ms to 80 ms for Wireless-MCU, and from
> 230 ms to 80 ms for MCU-Wireless.
> ...
> Below are the same cases for fixed access depicted. Although delays
> are generally shorter, scales are kept the same for easy comparison
> with the previous figure.
> 50 100 150 200 250 300 [ms]
> +---------+---------+---------+---------+---------+---------+---> t
> |
> | Fixed UA to Fixed UA
> +------------+
> | SIP | 65
> +----+-------+---------------------------+
> |RTCP| 25 | 205
> +----+-----------------------------------+
> |
> | Fixed UA to MCU
> +---------+
> | SIP | 50
> +---+-----+-----------------------+
> | | 15 RTCP | 200
> +---+-----------------------------+
> |
> | MCU to Fixed UA
> +---------+
> | SIP | 50
> +---+-----+-----------------------+
> | | 15 RTCP | 200
> +---+-----------------------------+
> |
> As can be seen, there is no obvious winner in all cases. RTCP is
> definitely more compact, even when using SIP SigComp. Regarding response
> time, RTCP is more beneficial unless it is subject to unfavorable
> scheduling rules, too low bandwidth, or both, in which case SIP can
> perform better.
> This rises further questions to be able to make an informed choice:
> * Are there other, general, reasons or recommendations that should
> be taken into account when choosing signaling technology?
> * What should the signaling strategy be when there are multiple nodes
> that need the signaled information, possibly not being in the direct
> route between the signaling peers?
> My own conclusion is that I would prefer using RTCP for this type of
> media stream-related signaling, since:
> * The media stream-related signaling does not have any major impact on
> the session itself, only what can be considered normal in-session
> variations, and thus there should be no need to notify all session-
> handling functions via SIP
> * All media-handling nodes are already in the media path and will
> automatically have access to this new signaling, but may of course
> have to implement support for it if they need to act on it
> * The difference in signaling bandwidth is definitely in RTCP's favor
> * The RTCP signaling delay has a clear potential to be lower than SIP
> and it should already be possible to configure RTCP such that this
> low delay can be achieved in a large majority of cases
> Comments on the above are greatly appreciated!
> Cheers,
> Bo Burman
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB | Phone [phone]
> Färögatan 6 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai