[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

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?

	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