subsequent (in-dialog) requests are already sent to a specific UA
instance by virtue of the Contact header and the Record-Route for the
dialog.
I agree that in-dialog requests are already "sent to a specific UA by virtue of Contact". However, my understanding is that Record-Route headers are "only" required for the GRUU draft because GRUU are advertised in the Contact header fields, and not because of a use-case related requirement.
The point of GRUU is to allow out-of-dialog requests to target a
"specific instance" in the same way that in-dialog requests do. No more, no less.
The point is that additional processing is needed by the current draft in home proxies. To remove this (not-needed?) burden, one could imagine other ways to advertise the GRUU (e.g. a Contact-Gruu header field) instead of advertising it in the Contact header field (e.g. in a 200 of INVITE). The remote user-agent would use this other way for initial requests (e.g. if it wants to send a SUBSCRIBE), without impacting the routing of mid-dialog requests in home proxies.
Paul
I'm sorry to bring this discussion so late, I just realize this lately.
Other minor comments:
p11: in the properties that a GRUU must exhibit, add that the host part of the URI must be equal to the host of the registrar that owns
the GRUU.
I don't agree that is a requirement. It could be a different host part that maps to the same IP, or a different host part that maps to a different IP but the same server, or it could map to a different server with access to the same location server.
Ok, agreed. However, maybe just rephrase my first proposal by indicating that the host part of the GRUU must be under the responsability of the domain that creates the GRUU.
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip