< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] RFC 5923 alias


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@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
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel