Francois Audet writes: > I am not sure why this is worded like this. I was thinking that using > a GRUU as a contact in a dialog-forming request would mandate that > requests sent to that Contact would be sent using the same flow, but > I see no such rule in draft-ietf-sip-gruu.
based on cullen's reply, text 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]. needs to be changed, because no matter gruu or not, ob needs to be included if UA wants the same flow to be used for requests of the dialog from the proxy. > Maybe I'm misunderstanding the question, but this draft relies on an > outbound proxy. So, in this specific example, the configuration server > needs to have outbound proxy behavior otherwise you are correct, this > NOTIFY won't be delivered. It's kind of like the co-located registrar > and proxy described explicitly in the document, but for co-located > Config server and proxy. 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"? -- juha _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
