On Oct 18, 2008, at 12:17 PM, Orsic, Milo (Milo) wrote:
Hi Dean,
Pertaining to Paul's posting below:
------------------------------
Well, the multiple flows are there for redundancy, right?
If one of the flows fails, the whole point is that things should
continue. If the UA gets upset receiving in-dialog messages on a
different flow, then things aren't working right.
Thanks,
Paul
======================
The UA will not get upset, since it may not receive the message.
Assume:
1. First registration between (UA's address) IP#1 via edge proxy#1
establishes the binding in the NAT/reflexive-firewall (and flow#1) -
as required by the draft.
2. Second registration between (UA's address) IP#2 via edge proxy#2
is used for redundancy, establishes the binding in the NAT/reflexive-
firewall (and flow#2) - as required by the draft.
3. Dialog is established using this flow#1 (and Route for this
dialog includes the edge proxy#1).
There was never a registration between IP#2 via proxy#1. Hence, any
in-dialog request (destined for the UA) sent from edge proxy#1
(since it is in the Route) to IP#2 will be filtered by the NAT/
reflexive-firewall.
As you can see by this example, the second registration - as
required by the draft - doesn't really creates a redundant flow.
IMHO, the draft should restrict the "redundancy" to a single contact
address (reached via different edge proxies).
Flow 1 goes from contact 1 through edge proxy 1, flow 2 goes from
contact 2 through edge proxy 2. Both flows are attached to a single
instance-id. The home proxy/registrar keeps track of the keepalive
status of each flow, and the keepalives keep the NAT binding open for
each flow.
Presume flow 1 is in-use for a dialog, and the flow fails. The home
proxy must then re-route the dialog to flow 2. This requires a fair
bit of mechanism in the proxy, mechanism that is not completely
defined in the outbound draft, but that can be readily inferred.
Another way to look at it is that Outbound routes to the "instance",
not to the "contact".
I think there is a little bit of confusion about gruu. Without
Outbound, the gruu is an alias for the conact. With Outbound, Is the
gruu an alias for the contact or the instance ? From a semantic-
clarity model, I think gruu needs to be an alias for the instance.
This however, is not completely clear to me in the current spec set.
--
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
