Slide
9 specifically uncovered a problem with outbound proxies that add a
Path URI but don't include a flow token.
The proposed solution is as follows. If a proxy inserts a Path
header
with a flow token consistent with the rules d
escribed in outbound, it MUST add the ;ob parameter to the proxy URI
that has the flow token.
The registrar verifies that any Path header URIs contain the ;ob
parameter. If there are any Path URIs without the ob
parameter, the registrar does not return Supported: outbound.
[CHH] Why would every Path header need to contain the ;ob parameter?
The
REGISTER request may traverse, in addition to the outbound proxy,
multiple proxies which insert a Path header. Do all these proxies
really need to support outbound?
Furthermore, the registrar needs to check that the first hop after
the
UAC is represented in the Path list (unless the
registrar recognizes that the first hop after the UAC is in the same
domain and doesn't need to include Path URIs with a
flow token). Note that this implies that whatever the proxy puts in
the Via (IP address or FQDN), it must put the same
hostname in the Path header (but there is no need for a complete URI
comparison). If the first hop is not correctly
represented, the registrar ignores the reg-id parameter and does not
return Supported: outbound.
[CHH] Isn't it much easier to mandate the outbound proxy to always
insert a Path header?
OR, another possibility is that the outbound proxy, if it detects that
the UAC supports outbound, insert some option-tag of itself in the
Supported header, to indicate to the registrar that it supports
outbound. Then the registrar does not need start looking at the Path
headers.
Regards,
Christer
The implication of this is that an outbound-proxy that supports
outbound needs to support Path and flow tokens for registrations to
all foreign domains. Inside the same domain, the first-hop proxy and
the registrar can still use Path to communicate with each other, but
they can use some other private mechanism to disaggregate this
functionality.
thanks,
-rohan
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip