[reSIProcate] RFC 5923 alias
Scott Godin
sgodin at sipspectrum.com
Wed Apr 11 07:55:21 CDT 2012
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 you
can try out the flow token mode of repro - this allows RFC5626 like
behavior for endpoints that don't support it:
# 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 at pocock.com.au> 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 at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20120411/daf50653/attachment.htm>
More information about the resiprocate-devel
mailing list