[Home]

Summary:ASTERISK-04404: [request] Multiple lines from one SIP provider treated as one line in logs and CDR
Reporter:tracy ing (usatracy)Labels:
Date Opened:2005-06-13 06:55:26Date Closed:2011-06-07 14:02:53
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When two or more lines are registered with the same SIP provider they are not treated as individual numbers in the logs and CDR and perhaps in other respects as well. Instead, asterisk appears to default to identifying them by the PEER information (host ip) instead of their user information.
Tested on AAH 1.1 and 0.8. Defualt install and installs including options and yum updates. All fail.

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

Various build of asterisk have been tested, with the * server nat'd and on the DMZ. Several different configurations have ben tried all to no avail. Have tested with inbound calls from stanaphone and broadvoice, same issue, if you have more than one trunk from a provider it will default to host IP to ID the line instead of the username for the trunk, leading to errors in the logs and CDR.

More info can be found at the asterisk at home thread included below. At least one other user has confirmed this as a problem.

https://sourceforge.net/forum/forum.php?thread_id=1300204&forum_id=420324
Comments:By: tracy ing (usatracy) 2005-06-13 06:57:56

sorry, link for reference was https

here is public link to ref doc.

http://sourceforge.net/forum/forum.php?thread_id=1300204&forum_id=420324
By: Michael Jerris (mikej) 2005-06-13 07:31:35

can we see some cli output on this.. it would be nice to see debug on 2 calls coming in from diff numbers, and of the registrations.  The bug says cvs HEAD, has that really been tested, as AAH is not head.
By: tracy ing (usatracy) 2005-06-13 10:09:16

I am not a Linux guru, I know how to turn on debug, how do I pipe it into an output I can capture like a file or something? I will look around to try and find out on my own, you can email me at usatracy@hotmail.com.

I have a sniffer and saw the two calls come in and the SIP messages appear to be correct, each has the correct phone numbers in them. But I will try to get the debug output and post it here. And I don't have a clue what CVS means, it was the default choice. As for downgrading to minor, until this is corrected we can't deploy asterisk. CDR would be wrong and calls can't follow proper inbound context unless we use the /EXT parameter in registration and force them to the correct destination that way.
Thanks
By: tracy ing (usatracy) 2005-06-13 11:11:39

OK, I figured out how to the data you want.

It is all at http://64.202.176.153/debug.txt

I included the config for the two Broadvoice trunks
The logfile from asterisk
and the debug output from the asterisk server.
This data has been cleansed, phone numbers and caller id are not the true data, used find/replace on them and inserted bogus data on all three data sets.

I made two or more calls to the two different broadvoice numbers, same thing, show up as one number in logs and cdr.
Thanks
By: tracy ing (usatracy) 2005-06-13 23:26:34

Here is a snippet from the debug, two calls, one to each number, each number has it's own reg and secret and are from the same provider/ip Broadvoice.

Instead of each call "finding the user context" with user being the SIP phone number, they "find the peer context" and the peer is wrong in one case.

7039551574 has a user of 7039551574 and a peer of bv7039551574
7035251632 has a user of 7035251632 and a peer of bv7035251632

In this example the both fail to find the user context and failover to the peer context. The choice to use the peer context bv7039551574 is arbitrary and based on a reboot and which one is registered first.

If rebooted and 7035251632 is registered first, then all calls from broadvoice will "find peer" bv7035251632.

I have tried natting, not natting, outside DMZ, inside DMZ with port forwarding. Is there some config option I am missing like externip or something globally that will cause asterisk to ignore matching user context and jump right to matching peer context instead on incoming calls ?

------------------------------------------------------------------------------------------------
Sip read:
INVITE sip:s@192.169.11.200 SIP/2.0
Via: SIP/2.0/UDP 147.135.0.128:5060;branch=z9hG4bK2ib7j03010p1m9gnu701.1sr
From: <sip:7034442834@147.135.0.129;user=phone>;tag=SD2021f01-665744939-1118713878031
To: "Trac Ing"<sip:7039551574@sip.broadvoice.com;user=phone>
Call-ID: SD2021f01-58d27abd7d6a5364c3593e2ba3f10077-js11002
CSeq: 1011190536 INVITE
Contact: <sip:7034442834@147.135.0.128:5060;ep=147.135.0.129;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,UPDATE,NOTIFY

�[Kasterisk1*CLI>
Supported: 100rel,timer
Min-SE: 60
Accept: application/sdp,application/dtmf
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 285

v=0
o=BroadWorks 39269 1 IN IP4 147.135.0.128
s=-
c=IN IP4 147.135.0.128
t=0 0
m=audio 13920 RTP/AVP 0 8 2 18 96 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:18 G729/8000
a=rtpmap:96 iLBC/8000
a=rtpmap:101 telephone-event/8000

14 headers, 13 lines
Using latest request as basis request
Sending to 147.135.0.128 : 5060 (non-NAT)
Found peer 'bv7039551574'
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 2
Found RTP audio format 18
Found RTP audio format 96
Found RTP audio format 101
Peer audio RTP is at port 147.135.0.128:13920
Found description format PCMU
Found description format PCMA
Found description format G726-32
Found description format G729
Found description format iLBC
Found description format telephone-event

______________________________________________________

Sip read:
INVITE sip:s@192.169.11.200 SIP/2.0
Via: SIP/2.0/UDP 147.135.0.128:5060;branch=z9hG4bK2ib7j93068e0s8kjq1c1.1sr
From: <sip:7034442834@147.135.0.129;user=phone>;tag=SD2gi9001-1949617339-1118713896319
To: "Trac Ing"<sip:7035251632@sip.broadvoice.com;user=phone>
Call-ID: SD2gi9001-d8aebd80756cbf71952bc309f48e8caa-js11002
CSeq: 1011199680 INVITE
Contact: <sip:7034442834@147.135.0.128:5060;ep=147.135.0.129;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,UPDATE,NOTIFY
Supported: 100rel,timer
Min-SE: 60
Accept: application/sdp,application/dtmf
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 285

v=0
o=BroadWorks 39623 1 IN IP4 147.135.0.128
s=-
c=IN IP4 147.135.0.128
t=0 0
m=audio 14196 RTP/AVP 0 8 2 18 96 101
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:18 G729/8000
a=rtpmap:96 iLBC/8000
a=rtpmap:101 telephone-event/8000

14 headers, 13 lines
Using latest request as basis request
Sending to 147.135.0.128 : 5060 (non-NAT)
Found peer 'bv7039551574'
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 2
Found RTP audio format 18
Found RTP audio format 96
Found RTP audio format 101
Peer audio RTP is at port 147.135.0.128:14196
Found description format PCMU
Found description format PCMA
Found description format G726-32
Found description format G729
Found description format iLBC
Found description format telephone-event
By: tracy ing (usatracy) 2005-06-18 08:48:45

I am going to add that this "minor" bug has created "major" problems in that all sip trunks from the same provider will only follow one context and is hampering the capability to provide individual call treament to the sip trunk based on its USER_CONTEXT. The temporary work around is to use the EXT parameter on registration and create a phantom registration and route from that, but it should follow the USER_CONTEXT for the trunk, but it doesn't.
By: tracy ing (usatracy) 2005-06-18 08:49:36

I am going to add that this "minor" bug has created "major" problems in that all sip trunks from the same provider will only follow one context and that is hampering the capability to provide individual call treament to the sip trunk based on its USER_CONTEXT. The temporary work around is to use the EXT parameter on registration and create a phantom extension registration and route from that, but the SIP trunk should follow the USER_CONTEXT for the trunk, but it doesn't.
By: Mark Spencer (markster) 2005-06-18 11:49:43

You can route by DID.  Just send the call wherever you want it to go, this is totally an extensions.conf issue.  If you need help, join #asterisk.
By: tracy ing (usatracy) 2005-06-18 12:01:13

There are 4 issues, none have been resolved by your closure comment.

1- Asterisk WIKI states
Incoming SIP Connections  
When Asterisk receives an incoming SIP call, the SIP Channel Module first tries

(1)- to find a [user] section matching the caller name (From: username),  

(2)- then tries to find a [peer] section matching the caller's IP address.  

(3)- If no matching user or peer is found, the call is sent to the context defined in the [general] section of sip.conf.  

This is NOT happening on SIP calls from the same provider/IP, it is failing over to number 2, the first choice number 1 is not happening.


2- Because number 1 is not happening, the CDR uses the default user context for the FIRST sip line registered with the provider, all CDR calls are tagged in error againts the wrong SIP phone number.

3- Because number 1 is not happening, the Asterisk log files is doing the same thing and all references are to the wrong sip line.

4- Calls are not following their user context, they are following the user context for the first SIP line registered with the provider. If they did not follow ANY context, that would be one things, but hey follow the first registered context in error.

I believe this issue needs to be re-opened and examiend more closely unless you can tell me what I have done in my config to prevent asterisk from operated as it should (as described above in number 1 for it's treatment of an inbound SIP call and matching the user in FROM.

Thanks
By: Mark Spencer (markster) 2005-06-18 12:15:29

1) It *is* happening, the user is the *from* not the *to*.

2) You can change account code based on DID.

3) The matching is happening in accordance with the description.  Since it doesn't match on from, it matches on IP.

4) Look at your own debug, in both INVITE requests the "From" is identical.  You can simply jump into a different context based on DID.

Again, please do not reopen until you've talked to someone on IRC who knows what they're doing (preferably a bug marshall as listed on bugs.digium.com).

Mark
By: tracy ing (usatracy) 2005-06-20 13:43:24

OK, I see what you are saying, so I am ammending my bug report to say that Asterisk, by design, is not handling inbound SIP calls in a manner that makes sense.

Why would one want to match based on the FROM as a first routing choice if any one of a billion people could be calling ? Great fetaure, but first it should match on the NUMBER the SIP provider provided which is the number the caller dialed to reach me.

I don't understand what you mean by using account and DID. I do not have DID circuits, I have SIP circuits. I have been in telephony over 20 years and I know what a DID is and how they work. My SIP provider sold me 6 lines, I can get 6 calls, you  have to dial 6 diffeent numbers to ring all 6 lines. The callers call each of these lines independently using a certain phone number. There is no "DID" being pumped in from the SIP provider either via DTMF or SIP header.

When the line rings in it should peg against the SIP number they dialed (the TO header), that way I know what line they called in on and I can bill for it  and route it accordingly.

If I ordered my 6 lines from 6 different carriers with 6 unique source IP's, then Asterisk would CDR and LOG correctly ony because the secodn choice is route by IP and they would each have their own context.

Matching by the FROM (the person calling and not the trunk they dialed) as a first choice doesn't make sense and would not be an acceptable first choice on any phone system I have ever installed.

I have two thousand people at one site, asking each of them to provide a list of who may call them so I could build a list of who to route inbound callers to based basically on caller id makes no sense at all.

Thanks
By: Michael Jerris (mikej) 2005-06-20 15:19:50

Changed this to a feature request as you can already do everything you want to do, you would just like to enhance the functionality.
By: Michael Jerris (mikej) 2005-06-26 18:45:14

No response to your feature request in a week.  Please move this request to the bounty section of the wiki, contract somone to do the work, or attempt to code it your self.  This bug can be re-opened when there is a patch ready to review.  Thanks.