Subject: Re: [Sip] Usage of flows in draft-ietf-sip-outbound-03

From: Cullen Jennings <[email-masked]>
Date: Wed, 31 May 2006 22:59:26 -0700

On May 31, 2006, at 7:16 AM, <[email-masked]>  
<[email-masked]> wrote:

>
> Hi,
>
> While reading draft-ietf-sip-outbound earlier I got (a wrong)
> idea that the UA would use those flows it has set up towards
> the outbound-proxy-set during registration, for sending any
> other requests thereafter. However this is not the case.
> When thinking this a bit more I found two use cases and
> different problem with each of them and I would like to get
> some answers how the next version of the draft should deal
> with those:
>
> 1. Sending request to first hop other than outbound proxy
>
> Sections 4.3.1 and 4.3.2 tell that the "The UA performs normal
> DNS resolution on the next hop URI (as described in RFC 3263)
> to find a protocol, IP address, and port." and "If the UA
> cannot use one of the existing flows, then it SHOULD form a new flow
> by sending a datagram or opening a new connection to the next hop, as
> appropriate for the transport protocol."
>
> Is the UA expected to keep this new flow alive ?

No - if it is important for this flow to stay alive, it will use a  
GRUU in the contact which will end up with routing over one of the  
flows that is alive. This is out of the scope of outbound.

> If yes, how long ?
> I do not think it is a valid requirement for the UA to keep a flow
> alive forever towards any proxy the UA has communicated with. But
> the draft does not suggest any rules about when the flow should
> be closed. For the flow related to registration I believe the flow
> can be cleared after removing the registration binding, but what
> about a flow the UA has opened when initiating a call through
> some other proxy than the outbound proxy e.g. due to 305 response ?
>
> 2. Sending registration refreshes
>
> I believe that draft-ietf-sip-outbound is written with the
> assumption that when the UA refreshes a registration binding
> the REGISTER message would be sent over the same flow over which
> the binding was created, right ? Or at least that the refreshed
> REGISTER would reach the same target host (outbound proxy) that
> received the very first REGISTER request, now to be refreshed ?
>
> However this is not guranteed. When sending the REGISTER refresh,
> the UA is supposed to use DNS procedures of RFC 3263 for resolving
> the URI of the outbound proxy. While doing that the UA may find a
> number of SRV records for that URI, having equal priorities and
> equal or different weights. Basically according to RFC 2782 the UA
> would select the used SRV record by random, possibly a different
> target host than the one used previously.

I think Robert has or working on a draft with fixes this. It's not  
clear this is what 3263 says should happen. Let me take TCP - if you  
have an TCP connection to example.com, clearly you want to reuse that  
not open a new one for every transaction.

> Is this a problem for
> SIP Outbound (while it is not a problem in RFC 3261 point of view)?
>
> What happens in this case:
>
> - Should the UA keep the flows now alive to those two proxies
>   for the same refreshed registration or should it silently drop
>   the first one ? I believe keeping all those flows open would
>   be an unnecessary burden, especially for mobile devices with
>   a battery.
>

Yes - clearly we want to send things in the same dialog on an  
existing connection if we have one.

> - Is there any risk that a proxy or registrar would try to use
>   such a flow towards the UA that is no more existing ?
>
> I would hope the next version of the draft would explicitely specify
> either that the UA is supposed to use the existing flow instead of
> performing RFC 3263 processing for the refreshed REGISTER or that
> the UA should drop the flow it had with the target host it used
> earlier, when receiving the 200 OK for the REGISTER.
>

One of the things we got wrong in much earlier version of outbound  
was trying to fix every routing problem in sip in one document  
including high availability and stateless server design. We are  
definitely trying to push things that are orthogonal to be solved  
separately.

> Feel free to tell me if I got it wrong at some point.
>
> Regards,
>
> Erkki Koivusalo
>
> _______________________________________________
> 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

_______________________________________________
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: <[email-masked]>
Date: Thu, 1 Jun 2006 11:03:17 +0300

Hi,

>flows that is alive. This is out of the scope of outbound.

Hmmm, I was just thinking about a situation where the UA, for some
reason or another, would send an INVITE towards any other proxy than
the outbound proxy. If that proxy record-routes and the flow would not
be kept alive, then the remote end could no more get the BYE back to
the UA.

Are you saying that there should be no reason whatsoever for the UA 
to use other proxy than the outbound one ? (Preloaded route from a 
game application, 305 response from the network etc. )

>definitely trying to push things that are orthogonal to be solved  

Or are you rather suggesting that if anything like that happens, 
it is not in scope of draft-ietf-sip-outbound to try to fix the 
resulting problems ? In other words: to traverse the NAT, the UA
has better to always use its persistent flows towards the outbound
proxy, no matter what.

Regards,

Erkki

>-----Original Message-----
>From: ext Cullen Jennings [mailto:[email-masked]] 
>Sent: 01.June.2006 08:59
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]
>Subject: Re: [Sip] Usage of flows in draft-ietf-sip-outbound-03
>
>

---

From: <[email-masked]>
Date: Thu, 1 Jun 2006 11:28:08 +0300

Hi,

Excuse me for my previous questions in this thread, I was just too
quick for pressing the send button before applying enough thinking :-)

>>flows that is alive.

>be kept alive, then the remote end could no more get the BYE back to

I have been looking things recently too much from the UA perspective
and were not very familiar with GRUU either. But I assume what Cullen
meant is that even if the first hop proxy that the UA uses would
record-route, the fact that the Contact header of such an INVITE
contains the GRUU would make sure that the proxy would eventually 
route any mid-dialog requests from the other end towards the
outbound proxy that has the flow with the UA. So this would be
the way to solve the problem with GRUU and Outbound together ?

Regards,

Erkki

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 01.June.2006 11:03
>To: [email-masked]
>Cc: [email-masked]
>Subject: RE: [Sip] Usage of flows in draft-ietf-sip-outbound-03
>
> 
>Hi,
>