On Oct 17, 2008, at 4:40 AM, Juha Heinanen wrote:
Elwell, John writes:
It is not clear why would need anything else. Why would you need to
parallel fork to the same instance ID, when you can use different
instance IDs?
just one clarifying question:
it was not clear to me if separate instance ids need to be used for
different contacts of the same ua, can a single register request
contain
both contacts and their instance ids? for example, if my ua has two
contacts and ob set has two proxies, does my ua need to send two or
four
register requests?
if four, i cannot accept a draft which causes such a mess.
Keep in mind that the processing of the REGISTER request forms the
flow-path. As the request and response traverse the proxies, the
information needed for service-route and path are discovered and stored.
Let us first think about registrations from different physical
interfaces. Since the edge proxy on each interface is likely to be
different, the flow-path needed for each registration is different.
Clearly each outbound registration from a different interface requires
a separate REGISTER request in order to assure formation of a correct
flow-path.
In the typical outbound case, the edge proxy is also different for
each reg-id. That's the goal of the redundancy function of outbound --
allowing multiple edge proxy bindings. Since the edge proxy is
recorded into the flow-path by the passage of the REGISTER request and
response through that proxy, separate REGISTER requests would appear
to be needed for each edge proxy (and consequently for each reg-ID
from a given instance).
So the general solution for two instances, each of which has two
registration flows through different edge proxies, would appear to
require for REGISTER requests. This model provides full single-failure
interface redundancy, flow redundancy, edge-proxy redundancy,
transport redundancy, and possibly (depending on the registrar design)
registrar redundancy, and provides multiple-failure redundancy in a
number of scenarios. More importantly, it allows survivability for a
dialog in the event of any single failure (except perhaps a total
registrar failure).
Now it is entirely possible, Juha, that you have in mind some sort of
reduced case-case use for Outbound. I think what you want requires two
instances, each of which has a single flow-path to the registrar.
Thus, only two registrations would be required. This provides a weaker
survival model in-dialog than the two-instance/two-flow (2x2) model,
but has a different recovery model than the one-instance/two-flow base
model of Outbound. There might be cases where this is seen as more
suitable, although I can't identify one off-hand.
--
Dean
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
