[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Question on REGISTER
> -----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).
>
> > 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.
>
> 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