[Asterisk-Dev] [BUG?] chan_sip, RFC 3261 and multiple UACs registering for one account

[Hartwig Deneke]

Alex at pilosoft.com wrote:
 >That's correct behavior. Plus, this is not subject for -dev.
 >  -dev is not 'court of appeals' from -users list.

Just to clarify the intent for my message. This was not meant as a 
feature request, but a bug report. I do think -dev is appropriate for 
bug reports, or not? Yes, I might be wrong, but you have not convinced 
me yet.
I respect the decision of Asterisk developers to  support only one 
device per channel. However, from a usability perspective, it seems 
terrible to let the REGISTER requests of two devices succeed 
successfully, making both devices think they are in REGISTERed state, 
while this is actually not the case. It would be far better to fail the 
second registration then.

 >> -----Original Message-----
 >> From: asterisk-dev-bounces at lists.digium.com
 >> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of
 >> alex at pilosoft.com
 >> Sent: Sunday, 28 August 2005 3:35 AM
 >> To: Asterisk Developers Mailing List
 >> Subject: Re: [Asterisk-Dev] [BUG?] chan_sip, RFC 3261 and
 >> multiple UACsregistering for one account
 >>
 >> Because REGISTER overrides current registration. You need to
 >> submit REGISTER with multiple contact addresses to get what you want.

Tim Robbins wrote:
 >This is incorrect. Adding a new binding does not implicitly remove 
 >unrelated bindings. Please read section 10 of RFC 3261.

I also do not see anything which would imply that modifying an unrelated 
binding is allowed. Also, submitting a REGISTER with multiple contact 
addresses does not work.
Command to test:
sipsak  -vvv -x 3600 -U -C 
'<sip:phone1$(MYDOMAIN)>,<sip:phone2$(MYDOMAIN)>' -a $(PWD) -s  sip:$(AOR)

Response by Asterisk for both scenarios
Asterisk Response:
 >SIP/2.0 200 OK
 >Contact: <sip:phone1@$(MYDOMAIN)>;q=0.00;expires=3600
 >Server: Asterisk(AOR)
Also here, there is only one contact.

While testing this, I discovered another behavior which I consider a 
violation of RFC 3261, see Section 10.2.3 Fetching Bindings
 >A success response to any REGISTER request contains the complete list
 >of existing bindings, regardless of whether the request contained a
 >Contact header field.  If no Contact header field is present in a
 >REGISTER request, the list of bindings is left unchanged.
Command to test:
sipsak  -vvv -x 0 -U -C empty -a $(PWD) -s sip:$(AOR)
Reply by Asterisk:
 >Contact: <>;expires=120
sipsak indeed sends no Contact header, if empty is specified as 
command-line parameter. Asterisk does not find the Contact field, and 
assumes an empty contact, which is used to overwrite the previous 
contact. So anyone wanting to query for currently registered contacts, 
e.g. to verify a successful registration  will kick out just this 
registration.

So should I open bug reports for these two items, or do Asterisk 
developers still find these behaviors acceptable?

Thanks,
Hartwig