Re: [reSIProcate] RFC 5923 alias
On 11/04/12 14:55, Scott Godin wrote:
> Hi Daniel,
>
> If you can use RFC5626 support, then RFC5923 is not required. There is
> more functionality gained with RFC5626 use (ie. doesn't require TLS
> transport, provides a heartbeat mechanism, etc.). I'm also not sure
> offhand if Polycom supports RFC5626 or not. However if it doesn't then
I've checked: Polycom confirm that reg-id (RFC5626) is not supported in
the current firmware.
I'd be quite happy just to use RFC5923 with the restriction that it is
requires TLS, as I want TLS anyway. I find that without TLS, there is a
risk of SIP-aware routers mangling the SIP packets, and that conflicts
with ICE.
I notice some of the Microsoft variations are supported (epid,
proxy=replace type stuff)
> you can try out the flow token mode of repro - this allows RFC5626 like
> behavior for endpoints that don't support it:
I tried that, I'm not 100% sure about the way these settings interact:
if I do EnableFlowTokens=true, then does the setting of DisableOutbound
make any difference?
How about the relationship between ClientNatDetectionMode and
EnableFlowTokens? Does EnableFlowTokens supercede
ClientNatDetectionMode, or do they work together in some way?
> # Enable use of flow-tokens in non-outbound cases
> # WARNING: Before enabling this, ensure you have a RecordRouteUri setup,
> or are using
> # the alternate transport specification mechanism and defining a
> RecordRouteUri per
> # transport: TransportXRecordRouteUri
> EnableFlowTokens = false
>
> It should be noted that some edge functionality of SIP will be broken
> with this mode. Byron has documented this in InteropHelper.hxx:
> // .bwc. If this is enabled, we will record-route with flow tokens
> // whenever possible. This will make things work with endpoints
> that don't
> // use NAT traversal tricks. However, this will break several things:
> // 1) Target-refreshes won't work.
> // 2) Proxies that do not record-route may be implicitly included
> in the
> // route-set by this proxy, because a flow token may point to them.
> // 3) Third-party registrations won't work.
>
> Scott
>
> On Tue, Apr 10, 2012 at 7:37 PM, Daniel Pocock <daniel@xxxxxxxxxxxxx
> <mailto:daniel@xxxxxxxxxxxxx>> wrote:
>
>
>
>
> I'm just trying repro with a Polycom device that is behind NAT,
> using TLS
>
> When the device tries to register, I notice that repro can't send the
> 407 challenge back to the device over the TLS connection. The log just
> says `discarding stray response: SipResp: 407 tid=8b5....'
>
> The Polycom device appears to support the `alias' attribute in the Via
> header, for re-use of the TLS connection:
> http://tools.ietf.org/html/rfc5923
>
> repro supports RFC 5626 (reg-id in the Contact header), but I'm not sure
> if the Polycom handset supports that
>
> Can anyone comment on either of these solutions, i.e. is 5923
> appropriate, has anyone got support for it in a branch somewhere
> perhaps?
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> <mailto:resiprocate-devel@xxxxxxxxxxxxxxx>
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>