Subject: [Sip] Question on REGISTER

From: [email-masked]
Date: Mon, 16 Oct 2006 13:48:08 EDT

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.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Oct 2006 16:19:27 -0400

[email-masked] wrote:
> one user before we can send a REGISTER for a second user? 

Nah, that's BS.

This prohibition applies to a single UA. You should view your gateway as 
being logically a bunch of UAs, one for each user it represents and 
registers.

This is true for a "two line phone" as well. The registrations for the 
two lines are separate.

BTW, in the future you should send such queries to 
[email-masked].

	Paul

> This is what we  are

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Oct 2006 00:56:33 -0500

> for stateless proxies to be in the path, where they would not be able to do  

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Oct 2006 10:27:44 -0400

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:
> [email-masked] 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:
>>
>> 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.
>

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 17 Oct 2006 21:44:40 -0500

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.

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.

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:[email-masked]] 
> Sent: Tuesday, October 17, 2006 9:28 AM
> To: Dean Willis
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] Question on REGISTER
> 
> 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:
> > [email-masked] wrote:
> >> 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 
> > 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.
> > 
> > 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
> > 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
> > 
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 09:16:20 -0400

> 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.

> transactions aren't overlapping.

overlapping how?

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 18 Oct 2006 09:56:26 -0500

> Sent: Wednesday, October 18, 2006 8:16 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Dean Willis; [email-masked]; [email-masked]
> > 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?
> 

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).

> > overlapping registrations from two different sources trying to 
> > register for the same target resource in parallel as long 
> as their SIP 

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.

> > 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
> > 
> >> 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:
> >>> [email-masked] wrote:

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Oct 2006 12:49:15 -0500

On Oct 17, 2006, at 9:44 PM, Brian Stucker wrote:

> pacing

That's for sure. I believe the underlying problem is isomorphic to  
the TCP rate-control problem, and look at the complexity that fine- 
tuning that has involved over the years.

Fortunately it sounds like there are a relatively limited number of  
"senders" in this scenario, so that reduces the complexity a bit. But  
there's still plenty of room for rate-adaptive techniques like "slow  
start" and "transaction count windowing" and other stuff straight out  
of TCP.

One could certainly do a thesis project on optimizing the scnnario if  
one were so inclined.

--
Dean