Subject: Re: [Sip] Re: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt

From: Cullen Jennings <[email-masked]>
Date: Sun, 11 Jun 2006 15:46:36 -0700

On Apr 8, 2006, at 4:07 PM, Rohan Mahy wrote:

>>> 2 - section 11 says "the proxy stores the value of the Path  
>>> header field", this should be "the registrar"
>>
>> good catch.  thanks,
>> -rohan
>

fixed.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jun 2006 21:35:01 -0400

inline.

Rohan Mahy wrote:

>> [Jvb] This part I understood. Perhaps my question below wasn't clear. 
>> (1a) is about the moment a request comes in destined for an AoR which 
>> has 2 registered contacts. At least one of them (the most recent one) 
>> has an associated flow, but the other has a higher q-value. Question 
>> is: which one gets selected?
> 
> 
> How the proxy selects specific instances (whether determined by unique 
> instance-id or contact URI) to make up the fork set is (still) proxy 
> local policy.  I know of several proxies that parallel fork all the 
> instances with the same q-value then wait and parallel fork the 
> instances with the next q-value.  Outbound doesn't change any of this.  
> Once you decide to try instance xyz then what flow you pick is described 
> in outbound.

I think I understand Jeroen's question and its not what you are talking 
about. Consider a single UA instance which registers two flows:

REGISTER
Contact: <sip:flow1@ua>
          ;+sip.instance="INSTANCE1"
          ;reg-id=1
          q=1.0

and then, 10 minutes later:

REGISTER
Contact: <sip:flow2@ua>
          ;+sip.instance="INSTANCE1"
          ;reg-id=2
          q=0.5

Now, we have two flows for the same instance. Flow 2 is the most 
recently registered flow for that instance, and per sip-outbound would 
be selected. HOWEVER, it has a lower q-value than flow 1. So, which 
precedence rule wins? Does the proxy pick the flow that is most recently 
registered, or that has the highest q-value?

I would argue that the q-value based selection is ONLY applicable for 
choosing between different instances, and that q-value is basically 
irrelevant for choosing between flows to the same instance. The spec 
should probably make this clearer.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 13 Jun 2006 07:37:47 -0400

inline
----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Rohan Mahy" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 12, 2006 9:35 PM
Subject: Re: [Sip] 
Re:http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-03.txt

>>> has an associated flow, but the other has a higher q-value. Question is: 
>>> which one gets selected?
>>
>>
>> instances with the same q-value then wait and parallel fork the instances 
>> with the next q-value.  Outbound doesn't change any of this.  Once you 
>> decide to try instance xyz then what flow you pick is described in 
>> outbound.
>
> Now, we have two flows for the same instance. Flow 2 is the most recently 
> registered flow for that instance, and per sip-outbound would be selected. 
> HOWEVER, it has a lower q-value than flow 1. So, which precedence rule 
> wins? Does the proxy pick the flow that is most recently registered, or 
> that has the highest q-value?
>

I disagree here. Outbound says "If the instance-id and reg-id are the same 
as a previous registration for the same AOR, the proxy uses the most 
recently created registration first". The 2 contacts in your example are for 
2 different reg-ids. The UA is expressing a preference for the proxy to use 
the flow for reg-id 1 over the flow for reg-id 2. In this case, I would 
think the proxy would use the reg-id 1 flow if it is still alive.