[IPFIX] sip-msg-02 SIP messages and aggregation

Hi!

My main interest is to write a single data record describing an
entire SIP dialog (e.g. a call between two parties) and not
a single SIP message.

Below are numerous points where I feel the current definition
may clash with that use case.

2.1 sipObservationType

There is a 'receiver' and 'sender' metering process type for
metering processes co-located with the SIP entity.
I case I want to aggregate multiple SIP messages into a single
entry what should I set here?
It does make a different whether the monitoring process was
co-located with the device or whether it pass 'mid-point'
(option 3 aka 'passive').

Another way of looking at the sipObservationType would be
'unknown', 'co-located' (aka 'end-point') and 'mid-point'.
This drops the 'sender'/'receiver' differentiation.
Could we extend it to have both bits of information encoded
in the sipObservationType?

2.5. sipFromURI
2.7. sipToURI

Would this include URI parameters?
sample: sip:user:password@host:port;uri-parameters?headers

This effectively duplicates the 2.6. sipFromTag and
2.8. sipToTag.

A system may opt to display sipFromURI and sipToURI which
may (rare case I guess) include the password. Often
sip:user@host would be enough, although it may be up
to the collector to remove unneeded bits.

2.9 sipCallId

Session-ID as defined in draft-kaplan-dispatch-session-id-03
won't be added for now as it's not a WG item, correct?

2.10. sipResponseStatus

In case multiple SIP messages are aggregated into one record
this should be allowed to hold the 'final response', e.g.
a 408 timeout even multiple callees responded with 486 or
early media (180, 183, ...).

3.1. sipContactURI

In the 'aggregated information' usage scenario there would
be (at least) two Contact URIs, e.g. named sipCallerURI and
sipCalleeURI (or UAS/UAC).

4. Template additions

For an aggregated 'sip session' the template would not only
need the observationTimeMilliseconds IE but also
a start/end time plus an optional PostDialDelay etc.
Essentially everything to calculate the RFC6076 SIP
performance metrics.

Finally we should allow SIPS URIs in the SIP URI fields or
point out that this is not intended.

Should I contribute a separate document with additional
Information Elements needed to describe SIP sessions
and a matching recommended template?

Regards,
 Hendrik

-- 
VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg   Germany
Phone +49 40 688 900 163    Fax +49 40 688 900 199
Email [email protected]   Web http://www.voipfuture.com

CEO Jan Bastian
Commercial Court AG Hamburg   HRB 109896
VAT ID DE263738086

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix