Hadriel,
You have excellent timing - we were about to submit a new version of the
draft to address various DISCUSS comments, so we have fixed both of your
issues below. You are correct that the CallID should be the dialog it
is reporting about, and the normal Request-URI rules should be followed.
Thanks,
Alan
Hadriel Kaplan wrote:
Howdy,
draft-ietf-sipping-rtcp-summary-05 has a body field named "CallID", which it says "provides the call id from the SIP header". Does this mean it's the Call-ID from the NOTIFY/PUBLISH request, or from the call it's reporting about? The examples show it's from the NOT/PUB message, but I don't understand the value of putting that in the body, compared to the one from the call being reported about.
The draft also says "The REPORTER SHALL populate the Request-URI of the NOTIFY method with the address of the COLLECTOR." AFAIK, the Notify should follow the Subscribe dialog, and thus the req-uri should follow the rules for any in-dialog requests per 3261.
-hadriel
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
