6 Dec
2012
6 Dec
'12
9:55 a.m.
6 dec 2012 kl. 15:24 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Olle E. Johansson writes:
One registered device has TWO registrations that I belive should have
the same Q.
where is that specified? outbound rfc does not have a single word about
q.
We've discussed this for a long time during the last SIPit. You guys should
come
too :-)
You are right though. It must be an oversight. Treat my statements as my
personal implementation guidelines, nothing more. We should propably
take this to the sip-implementors list.
also, there is no mention that reg-id value has anything to do with the
order in which the contacts are tried. rfc says,
When a proxy uses the location service to look up a registration
binding and then proxies a request to a particular contact, it
selects a contact to use normally, with a few additional rules:
"normally" to me means ordered by q value. first additional rule places
a clear restriction:
o The proxy MUST NOT populate the target set with more than one
contact with the same AOR and instance-id at a time.
Exactly.
the next one is not clear to me:
o If a request for a particular AOR and instance-id fails with a 430
(Flow Failed) response, the proxy SHOULD replace the failed branch
with another target (if one is available) with the same AOR and
instance-id, but a different reg-id.
what if this another target has lower q than some other target?
Again, it seems
like the authors assumed that a UA sends the SAME register
contact across two different paths. It doesn't say so. It doesn't tell the
registrar
what to do if the contact uri and uri parameters are different for the two registrations
from the same device.
I don't really see any case where that happens. YOu normally configure a device
to register with this service using this q value. Finding the edge servers and
registering
with them is done using DNS or provisioning and there's no separate configuration per
edge proxy. So the Q value will in most cases be the same. But never say never :-)
/O
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev