[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