Streaming Media Supplement sa2150 and sa2250

107
Chapter 10 Logging and Monitoring
Forward proxy deployment
Default behavior.
(proxy.config.wmt.logging.origin_gets_original_url value is 0):
The origin server records its own IP address as the IP address in the content URL that the client requested.
Optional behavior.
(proxy.config.wmt.logging.origin_gets_original_url value is 1):
The origin server records the request with a content URL as it came from the Windows Media Player.
Reverse proxy deployment
Default behavior.
(proxy.config.wmt.logging.origin_gets_original_url value is 0):
The origin server records the request after Media-IXT has modified the request to include the origin server's
own IP address.
Optional behavior.
(proxy.config.wmt.logging.origin_gets_original_url value is 1):
The origin server records the request with a content URL as it came from the Windows Media Player.
Requests for non-existent files
The behaviors described above do not apply when an origin WMT server receives a request for a non-existent
file from Media-IXT. In this case, the origin WMT server invariably logs the IP address of Media-IXT rather
than the client as the source of the request.
About the prob field and WMT
Some number of bytes are logged as coming from server, even when Media-IXT is serving a WMT clip from
cache.
There are two reasons for this:
• When Media-IXT is serving a WMT clip from cache, a small number of bytes are still logged as coming
from server, because Media-IXT looks at metadata about the streaming content, and must obtain that some
of that metadata from the origin Windows Media server. This holds true whether the client is Windows
Media Player version 6 or Windows Media Player version 7.
• When the client is Windows Media Player 6, more bytes are logged as coming from origin server than when
the client is Windows Media Player 7. This is the result of player behavior, and is mostly noticeable when
the player is using TCP as an underlying transport protocol.
QuickTime Logging
For QuickTime, logging entries appear after the player tears down the connection to Media-IXT. This happens
a minimum of thirty seconds after a clip is finished playing. This behavior is unique to QuickTime, but it is not
a bug.
No QuickTime clip is ever served entirely from cache; Media-IXT pulls some small percentage of every
QuickTime clip from the origin QuickTime server, even when the clip is in cache. This is necessary because of
a characteristic of origin QuickTime servers, namely the use of a timeout header, that can cause the server to
tear down its connection to a player (or Media-IXT) arbitrarily. Origin QuickTime servers that are in your
administrative control should be configured to minimize this behavior. See “Configuring an origin QuickTime
server for use with Media-IXT” on page 94.
Media-IXT’s general approach is to download as much as needed from an origin QuickTime server, then switch
to playing from cache.
Because live streams are not cached, %<prcb> (the number of proxy response bytes to the client from Media-
IXT’s cache)
is always 0 for live streams.
In hierarchical live splitting deployments, QuickTime logging has some special characteristics.