[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Question on REGISTER
Brian Stucker wrote:
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: Wednesday, October 18, 2006 8:16 AM
To: Stucker, Brian (RICH1:AR00)
Cc: Dean Willis; sip at ietf.org; CLHaft at aol.com
Subject: Re: [Sip] Question on REGISTER
Brian Stucker wrote:
IMHO--
Having implemented registrars and things that register with them.
The RFC is designed to disallow registrations for the same target
resource at the registrar. This means that ANYONE trying to
register
against a particular target resource at the registrar must
wait their
turn and no overlapping is allowed (the target resource's
contact set
is not allowed to change in parallel). Once the 200 OK to one
registration is sent out though, the next guy in the queue
is free to do their thing.
Brian - are you saying that if two different UAs, X and Y,
are attempting to register to the same AOR, Z, that they must
coordinate with one another to prevent concurrent REGISTER requests?
How would you expect them to do so?
This is a serialization problem for the registrar, not the UAs.
No, that's not what I'm saying. The UAs are ignorant of one another, the
registrar has to queue up the requests. Sending back 491s to X or Y
makes no sense since they're using different SIP transactions entirely
(assuming they are).
OK, I misunderstood you.
This doesn't mean that the registrar has to send a 491 back to
overlapping registrations from two different sources trying to
register for the same target resource in parallel as long
as their SIP
transactions aren't overlapping.
overlapping how?
Standard SIP overlapping transactions... Two transactions with the same
SIP context information (callid, tags, etc) but the CSEQs are different
and a final response hasn't been sent for the transaction with the lower
CSEQ value when the transaction with the higher CSEQ is received.
That'll earn you a 491 from the SIP transaction layer in most cases.
I don't interpret this the same way that you do.
AFAIK that isn't a transaction layer issue at all. This is in fact ok in
some cases. For instance it is legal to send a 2nd NOTIFY before the
response has been received for an earlier one. (Often not wise, but
legal.) And if you have two dialog usages sharing a dialog, you might
have a NOTIFY and a reINVITE overlap.
Instead, my understanding is that 491 reflects a higher level (above the
transaction layer) conflict - namely at the dialog usage level. Its not
entirely clear to me whether 491 can be used for overlapping REGISTERs
in the same "dialog" or not. (The use of Call-ID with REGISTER doesn't
exactly mean that you have a dialog.) Maybe its use could be
rationalized in that case. But its much harder to rationalize its use in
other cases of colliding REGISTER requests.
Paul
Paul
You should only get a 491 if you have a pending
registration with the
same SIP transaction context information (tags, callid,
etc, matches a
registration that is still being processed).
BTW- You may want to have a systems engineer take a look at your
pacing algorithm. Depending on the timer intervals involved, you're
going to wind up with some wickedly sinusoidal traffic
patterns from
most obvious traffic spreading algorithms.
Check that.
Regards,
Brian
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: Tuesday, October 17, 2006 9:28 AM
To: Dean Willis
Cc: sip at ietf.org; CLHaft at aol.com
Subject: Re: [Sip] Question on REGISTER
I do agree with Dean on this.
I like the phrase "massive non-workingness". Another
Dean-ism for the
book.
The server you are registering to has no business sending
you a 491
when you send a second REGISTER to a different AOR. But it
certainly
can send you a 503 if you are trying to send 4000 concurrent
REGISTERs.
Paul
Dean Willis wrote:
CLHaft at aol.com wrote:
I'm working on a gateway between a proprietary system and
SIP. One
of our new projects involves sending REGISTERs on behalf
of some of
our users to a third party server. They are pointing at section
10.2 of RFC 3261 where it states:
UAs MUST NOT send a new registration (that is, containing new
Contact header field values, as opposed to a
retransmission) until
they have received a final response from the registrar for the
previous one or the previous REGISTER request has timed out.
Does this really mean that our gateway must really wait for a
response for one user before we can send a REGISTER for
a second
user? This is what we are being told by the third-party
vendor of
the registration server. I find it hard to believe that
this is the
intent of the RFC, especially since it allows for
stateless proxies
to be in the path, where they would not be able to do this.
Paul is correct that this section 10.2 text really refers
to REGISTER
requests with the same request-URI and To: value launched
by a single
UA, and its intent is to prevent "stacking up" of pending
requests
that are effectively going to cancel each other out anyhow.
However, you may still want to do some sort of flow control
or pacing
on a sequence of REGISTER requests. Many registrars will
fall over or
at least get blocked up and start dropping requests if
they're hit
with too many overlapping requests. This is why the "avalanche
restart" problem (where perhaps many UAs served by a single
registrar
reset at the same time due to a power failure) is such a
big problem for large systems.
Serializing the requests is probably the absolute safest
flow control
model. Note that this places no real dependencies on
proxies, just on
multiuser UAs. By serialization, I mean that the UA does
not start a
new register request until it has received a 200 OK (or
other final
response) to the preceding request.
More sophisticated systems might launch REGISTER requests at some
rate-per-second, with reasonable numbers for real
hardware probably
ranging from 4 to 400. Certainly if you drop 4,000 registration
requests on a server within a 1-second window you are
going to see
some massive not-workingness.
--
Dean
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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