Re: [Sip] configuration NOTIFY in example 9.1 of outbound i-d

[Paul Kyzivat <pkyzivat at cisco.com>]

Francois Audet wrote:
>>  > 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.

Gruu isn't dependent on outbound.

	Thanks,
	Paul

> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.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



Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org



Francois Audet wrote:
>>  > 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.

Gruu isn't dependent on outbound.

	Thanks,
	Paul

> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.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