- status: open --> closed-fixed
OPAL has a mode allowing to use RFC5626 mode registration.
Here are interesting parts regarding OPAL:
Talking about the following Contact header in a REGISTER :
Contact: <sip:bob@192.168.1.2>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Make note of both the 'reg-id' and 'sip.instance' contact header
parameters. They are used to establish an outbound connection tuple
as defined in [RFC5626]. The connection tuple creation is clearly
shown in Figure 5. This ensures that any inbound request that causes
a registration lookup will result in the reuse of the connection path
established by the registration. This removes the need to manipulate
contact header URIs to represent a globally routable address as
perceived on the public side of a NAT.
It means a UA will always try to use the existing connection if it exists. That's good because it fixes NAT problems. The RFC suggests that, at any time, two connections should be open toward the SIP proxy. IMHO this is not a huge problem if it is not the case soon with OPAL.
But also :
Each UA has a unique instance-id that stays the same for this UA even
if the UA reboots or is power cycled. Each UA can register multiple
times over different flows for the same SIP Address of Record (AOR)
to achieve high reliability. Each registration includes the
instance-id for the UA and a reg-id label that is different for each
flow. The registrar can use the instance-id to recognize that two
different registrations both correspond to the same UA. The
registrar can use the reg-id label to recognize whether a UA is
creating a new flow or refreshing or replacing an old one, possibly
after a reboot or a network failure.
When a proxy goes to route a message to a UA for which it has a
binding, it can use any one of the flows on which a successful
registration has been completed. A failure to deliver a request on a
particular flow can be tried again on an alternate flow. Proxies can
determine which flows go to the same UA by comparing the instance-id.
Proxies can tell that a flow replaces a previously abandoned flow by
looking at the reg-id.
When sending a dialog-forming request, a UA can also ask its first
edge proxy to route subsequent requests in that dialog over the same
flow. This is necessary whether the UA has registered or not.
UAs use a simple periodic message as a keep-alive mechanism to keep
their flow to the proxy or registrar alive. For connection-oriented
transports such as TCP this is based on carriage-return and line-feed
sequences (CRLF), while for transports that are not connection
oriented, this is accomplished by using a SIP-specific usage profile
of STUN (Session Traversal Utilities for NAT) [RFC5389].
The big problem, from my point of view, is that OPAL does not respect this:
When a flow used for registration (through a particular URI in the
outbound-proxy-set) fails, the UA needs to form a new flow to replace
the old flow and replace any registrations that were previously sent
over this flow. Each new registration MUST have the same reg-id
value as the registration it replaces. This is done in much the same
way as forming a brand new flow as described in Section 4.2; however,
if there is a failure in forming this flow, the UA needs to wait a
certain amount of time before retrying to form a flow to this
particular next hop.
In other words, OPAL specifies a RFC5626 compliant Contact, so the proxy thinks the UA supports RFC5626, but it does not. I think OPAL should detect connection failure and recreate any failed connection.
Damien