[Home]

Summary:ASTERISK-03645: Multiple SIP Registrations not being handled properly
Reporter:scrubb (scrubb)Labels:
Date Opened:2005-03-07 13:32:32.000-0600Date Closed:2011-06-07 14:10:14
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Summary:
When I register with two Broadvoice accounts, calls for the second account registered come into asterisk as if for the first account.  The channel is actually named based on the first account.

For example.  I have two accounts:  The numbers for this example are:
8885551212 and 8005551212.

In sip.conf I have:

Externip=192.168.1.1 ;this is a real address in my real file
dtmfmode=inband
context=broadvoice-in  ; Default context for incoming calls

register => 8885551212:password@sip.broadvoice.com
register => 8005551212:password@sip.broadvoice.com


When I dial the 8005551212 account I get an inbound call labeled:
SIP/8885551212-asdf.

The only way I can distinguish between them is to do a
SIPGetHeader(TO,To) and parse the variable.

When I packet sniff or use the SIPGetHeader, the invite from Broadvoice is correct.  

My "friend" definition is as follows:

[Broadvoice]
type=friend
username=8885551212
fromuser=8885551212
secret=password
host=sip.broadvoice.com
context=broadvoice-in
fromdomain=sip.broadvoice.com
nat=yes
canreinvite=no
dtmfmode=inband
port=5060
insecure=very
permit=147.135.0.128/32
qualify=yes

When I create another friend definition for the second account, neither works (neither register properly with BV).  Is this possibly and issue with NAT?



****** ADDITIONAL INFORMATION ******

This is very easily replicated and there is at least a report of another person on the -dev mailing list encountering this same problem.  I searched for duplicates but did not see any.  Please forgive if this has already been posted.
Comments:By: scrubb (scrubb) 2005-03-07 13:33:36.000-0600

Sorry, just noticed the category was accidentaly set to codec handling.  Can someone fix?

By: egnarf (egnarf) 2005-03-07 15:07:22.000-0600

Changed to registration.
(ps. Hope I didn't piss anybody off, I'm not sure if I'm allowed to do this =)

By: egnarf (egnarf) 2005-03-07 15:10:53.000-0600

Shouldn't you have different extensions after the register => line?
eg. register => 8885551212:password@sip.broadvoice.com/<extension>
so they get sent to different extensions?

By: Kevin P. Fleming (kpfleming) 2005-03-07 15:15:33.000-0600

When calls arrive at your system from Broadvoice, there is no identification as to which 'user' account should be used, since they arrive from the same IP and have no other identifying information.

The proper way to resolve this is, as egnarf mentioned, add an <extension> suffix to your register lines, and then routes the calls in the incoming context appropriately.

By: scrubb (scrubb) 2005-03-07 15:16:27.000-0600

Different extensions is one work around to deal with the issue.  However, the issue remains that Asterisk is fundamentaly confused about which number is included in the Invite.