Subject: RE: [Sip] How to indicate during proxy discovery that aproxysupports"outbound"

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 29 Mar 2006 22:01:18 +0200

Hi,

If we talk about a flag in the Path header (or Via header) I think we
need to look at it from a little wider, conceptual, perspective. 

What you are talking about is a way for proxies to indicate capabilities
and support of extensions. So, if my proxy is allowed to indicate
outbound, why can't it then also indicate support for session-timer,
PRACK, pre-conditdions, <insert-your-favorite-SIP-extension>? Shall we
only do a "hack" for outbound, or shall we look at it from a more
general perspective?

Regards,

Christer

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: 29. maaliskuuta 2006 22:44
To: Hadriel Kaplan
Cc: [email-masked]; 'Dean Willis'
Subject: Re: [Sip] How to indicate during proxy discovery that
aproxysupports"outbound"

Hadriel,

see inline

Jeroen

----- Original Message -----
From: "Hadriel Kaplan" <[email-masked]>
To: "'Jeroen van Bemmel'" <[email-masked]>
Cc: <[email-masked]>; "'Dean Willis'" <[email-masked]>
Sent: Wednesday, March 29, 2006 10:19 AM
Subject: RE: [Sip] How to indicate during proxy discovery that a
proxysupports"outbound"

> Hi Jeroen,
> Comments inline...
>
>> -----Original Message-----
>> From: Jeroen van Bemmel [mailto:[email-masked]]
>> Sent: Tuesday, March 28, 2006 1:14 AM
>>
>> > But there are 3261 compliant proxies out there that don't support
Path.
>> > So
>> > you will not know if the register went through one of those and hit

>> > an outbound registrar, vs. there was no proxy.  I think a 
>> > proxy-require is the only safe bet (and it would work across 
>> > multiple proxies).  It only
>> means
>> > an
>> > extra round-trip if it fails, and the truth is you do require the 
>> > proxy
>> to
>> > support something, so why not use the header defined for that?
>>
>> If the outbound proxy does not support Path, it also does not support

>> outbound. In either case the UAC could detect this (i.e. no Path 
>> header matching outbound proxy -> proxy does not support outbound). 
>> The problem could be with proxies that ~do~ support Path, but for one

>> reason or another do not wish to be in the path for inbound requests.

>> On the other hand:
>> keepalive is only required for the path that inbound requests follow!
>
> Actually, I'm pretty sure keepalive is required for the first sip box 
> the UA hits (the one outbound and inbound requests follow), because 
> your nat-hole-flow is to it.  I don't see how it's possible for your 
> Register to go to a first proxy which is not in both the inbound and 
> outbound request flow.  How would the request get back through the 
> nat-hole or TCP socket?
>

That was exactly my point: what happens if the first proxy does not add
Path? Assuming there is NAT (or something else preventing direct
reachability), the UAC would have to establish a flow with the next hop
on the path, i.e. the host corresponding to the last entry in the Path
header value (possible issue as you mention below). If there is no Path
header, it will have to connect directly to the registrar.

> More importantly, the local proxy could very well do Path but NOT 
> support outbound.  So you'll be doing it when you shouldn't.
>

The idea was to add a flag to the Path header. When the flag isn't
there, it means outbound is not supported by the proxy that inserted
that Path header (hence no STUN poking)

> Second, it may be just a registrar without a proxy (no path header).  
> So you won't be doing outbound when you should.  (at least, I don't 
> think a registrar supporting Path actually inserts it if it's an empty

> set, and it itself is not in the uri set)
>

I agree that the registrar wouldn't insert a Path header. So the rule
should
be: if there are Path headers, check if the last value contains a flag.
If no Path headers, check for Supported : outbound (and start keepalives
if found).

> Fourth, if it's a proxy that does Path, there is no assurance the URI 
> you get in the returned 200ok Path is its URI to you.  Proxies can 
> have multiple interfaces, and the Path URI will be the one pointing to

> the registrar, no?
> So you won't be doing outbound when you should.
>

I think this is a matter of properly defining semantics. A flag in the
Path 
header (or in the URI) would have to mean that the element supports STUN
on 
all interfaces. It could be that the UAC cannot match the URI in the
Path 
header to a host that it recognises / can reach, but I don't think it
needs 
to. Just looking for the flag in the last Path header would suffice

Jeroen

> -hadriel

_______________________________________________
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