Subject: [Sipping] Remarks on rtcp-summary

From: Huybrighs Joseph <[email-masked]>
Date: Tue, 28 Sep 2004 13:45:22 +0200

Some remarks regarding draft-johnston-sipping-rtcp-summary-03:

1. I basically agree with Dave Oran's remark that it would be better to also
include RTP stream information in the reported event. The SSRC seems to be
the logical choice for this but nevertheless, I doubt whether the dialog
parameters and the SSRC in practise will be of much help. Considering that
typically this type of information will be collected by an operator's
technician dealing with complaints, more relevant information will be needed
to identify the peer(s) of the RTP stream(s), helping to identify possible
reasons (e.g. network topology) for bad quality. I would think that the
peer's IP address is key here.

2. The new proposal describes the SIP PUBLISH method for reporting the
rtcp-xr statistics, which definitely makes the implementation and more
important the configuration of this in endpoints like IP phones, IADs, ATAs,
etc. a lot easier. SUBSCRIBE/NOTIFY puts quite a burden on the user agent
because of the provisioning, authentication and security requirements that
would be needed to only accept subscriptions from entitled parties.
If it is accepted for a User Agent to always send a PUBLISH request at the
end of a media session then I would suggest to take out the need for end
devices to also support the SUBSCRIBE/NOTIFY method. I assume that the
PUBLISH request in an operator network will go to the proxy server and that
from there SUBSCRIBE/NOTIFY will be used by the RTCP-XR collector.

3. One drawback of the PUBLISH method which I see is that it isn't really
fit for passing 'begin-of-session', 'mid-of-session' or 'threshold-overflow'
type of statistics that might be of interest for an operator. E.g. if a lot
of calls are being dropped because of bad quality in the first couple of
seconds of the call, then maybe the need comes up to send reports at regular
intervals during a single 'call'. Alternatively we might have to add in the
rtcp-xr event an indication how long the session has lasted.

4. Regarding the application/rtcp-xr format it seems strange to not encode
this in XML and I assume that this is done to keep the body of the message
short. I have no problem with this but it should be noted that PUBLISH of
course has some ressemblance to 'old' SNMP TRAP messages, which in next
generation networks (at least DSL access networks) will be replaced by
XML-based notifications (e.g. DSLForum TR-69).    

Jos

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP