>  > Section 4.3 states (UA procedures):
>  >    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].  
> 
> if contact is gruu, does it mean that 'ob' param is 
> implicitly included?

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.

Cullen/Rohan/Jonathan?

>  > Then, section 5.3.2 (proxy procedures):
>  >    For mid-dialog requests to work with outbound UAs, the 
> requests need
>  >    to be forwarded over some valid flow to the appropriate 
> UA instance.
>  >    If the Edge Proxy receives an outgoing dialog-forming 
> request, the
>  >    Edge Proxy can use the presence of the ob URI parameter 
> in the UAC's
>  >    Contact URI (or topmost Route header field) to 
> determine if the Edge
>  >    Proxy needs to assist in mid-dialog request routing.
> 
> if there is no edge proxy, i.e., UA sends subscribe directly 
> to a presence server, then does this draft not apply and 
> there is no mechanism for the UA to indicate that it wants 
> subscribe tcp connection to be reused by presence server for notifies?

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.
_______________________________________________
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

Reply via email to