Dean Willis writes:
So what do you think is broken now?
see my message a few days ago to the list. i have read only a few
percent of outbound text and at least this paragraph is broken:
If the UAC is sending a dialog-forming request, and wants all
subsequent requests in the dialog to arrive over the same flow, the
UAC adds an 'ob' parameter to its Contact header. Typically this is
desirable, but it is not necessary for example if the Contact is a
GRUU [I-D.ietf-sip-gruu]. The flow used for the request is
typically
the same flow the UA registered over, but it could be a new flow,
for
example the initial subcription dialog for the configuration
framework [I-D.ietf-sipping-config-framework] needs to exist before
registration.
also, i'm questioning why outbound i-d does not provide a general
solution to "usage of the same flow for in-dialog requests" problem:
outbound behavior is also needed in case of regular presence server.
that is why i don't quite understand is why is this "usage of the
same
flow for in-dialog requests" feature tied to outbound proxy. why
is it
not useful to have a generic capability for UAC to tell to the next
hop
(a proxy or UAS) in its dialog initiating request that "please use
this
flow for subsequent requests of this dialog"?