All the SIP calls entering by the same channel

hi!

As i wrote in the title my problem that i have is that currently on my box i have 5 sip trunks of the same provider (every trunk with his own user and password and properly registered with register string)

My main problem is that when im checking in the CDR for give the report to my friends who are paying the lines the CDR shows from indound channel ALWAYS the same channel for all, i want to mean i cannot determine by single report, which calls are incoming from which line.

is there any way that i can solve it?

Thanks in advance!

Assuming each trunk’s inbound and outbound context is unique, try using the CVS file option under ‘Report Type’.

hi!

the problem is that for example in my trunks (incoming) context i have:

Auth-2345
Auth-2954
Auth-4567

and the three incoming calls in the CDR i will look like they are entering (even in the CLI) from “Auth-2345”

Unless there is a bug of some kind I would say that all the calls really are coming in on the same trunk/channel. Perhaps your provider is routing them ALL in via the same registration. You can probably confirm this by temporarily disabling the other two trunks and making test calls. Also check your provider’s user portal and confirm the routing.

1 Like

I talked with another friend who works in another ITSP and also when we was using his lines we had the same problem, our “incoming” context in the trunks is in this way:

Line 1
Incoming
username=52664XXXXXX
type=peer
secret=password
qualify=yes
nat=yes
insecure=very
host=sip.domain.provider
fromuser=52664XXXXXX
fromdomain=sip.domain.provider
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
authuser=52664XXXXXX
allow=g729,g723

Line 2
Incoming
username=52800XXXXXX
type=peer
secret=password
qualify=yes
nat=yes
insecure=very
host=sip.domain.provider
fromuser=52800XXXXXX
fromdomain=sip.domain.provider
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
authuser=52800XXXXXX
allow=g729

(the XXXX it is only for mask the continue user for posting)

Verify your provider is sending the calls to the correct registrations. I would turn on the SIP debug in the CLI and pay close attention to the information there. You will most likely find some answers there.