Can't get direct incoming calls

[Dimitri]

Hello everyone,

 

I'm having a problem with the configuration of 10 extensions. I'm having 10 DID numbers in the style of 028809920 - 028809929. 3StarsNet (a Belgian provider) has given me 1 trunk for those 10 numbers. I've configured 10 extensions 20 till 29. On every extension I attached the phone number for example 29 028809929 (section: account number(s)). When making a call to one of those 10 numbers, the call is coming in and routed to extension 20. In Trunk, my send call to extension is empty ... I'm getting nuts. Can someone help me a bit further ... O yeah, I already read thousand times the old wiki.

 

Thanks,

Dimitri

[djanjic]

Can you post SIP Invite log for some of these calls, that can give us some clue. Which version are you using?

[Vodia PBX]

Quick questions: Are you using the outbound proxy on the trunks? Possibly also specify the associated addresses (for explicit inbound routing). The old wiki did not have the inbound routing setting, so that might be making a difference.

 

Also, the log (log level 9) can be very interesting when the PBX wants to make decisions where to route the call. Usually it log what trunk it identified and where it wants to send the call.

[Dimitri]

Yes indeed. I'm using the trunk for incoming and outgoing sessions ... So my outbound proxy is activated and using the IP from the provider 3StarsNet. This is the config of mu trunk:

# Trunk 2 in domain sip.test.com

Name: 3StarsNet

Type: register

To: sip

RegPass: ********

Direction:

Disabled: false

Global: true

Display: Test

RegAccount: 02xxxx620

RegRegistrar: 85.119.188.3

RegKeep:

RegUser: 02xxxx620

Icid:

Require:

OutboundProxy: 85.119.188.3

Ani:

DialExtension:

Prefix:

Trusted: false

AcceptRedirect: true

RfcRtp: true

Analog: false

SendEmail:

UseUuid: false

Ring180: false

Failover: never

Privacy: rpi

Glob:

RequestTimeout:

Codecs:

CodecLock: true

Expires: 360

FromUser:

Tel: false

TranscodeDtmf: false

AssociatedAddresses:

InterOffice: false

DialPlan:

Colines: co1 co2 co3 co4 co5

DialogPermission:

 

What do you mean with 'specify the associated addresses'?

 

I activated log level 9 (till now I only have messages of level 6. These look like this:

[5] 2010/12/14 15:11:50: Identify trunk (line match) 2

[6] 2010/12/14 15:11:50: Sending RTP for 6e7f7a60151ad3cb4640b2fa057bd6d6@85.119.188.3 to 85.119.188.31:10634, codec not set yet

[5] 2010/12/14 15:11:50: Global trunk 3StarsNet@sip.test.com sends call to 20 in domain sip.test.com

[6] 2010/12/14 15:11:50: Codec pcmu/8000 is chosen for call id 6e7f7a60151ad3cb4640b2fa057bd6d6@85.119.188.3

 

Thanks for your feedback.

Dimitri

[Vodia PBX]

AcceptRedirect: true

 

I would turn that off; otherwise your carrier can use your PBX for making outbound calls to expensive destinations. But I dont this this is your problem.

 

AssociatedAddresses:

 

That's the setting I was talking about. Some providers send you traffic from IP addresses that are not the registrar.

 

Do you have other trunks? Make sure that they have either the outbound proxy set or the AssociatedAddresses. Then for the incoming trunk you should see that the PBX matches it to the right trunk.

[Dimitri]

Hi everyone,

 

We are 2 months later and I still haven't found the hassle in the Snom One configuration. I adapted my settings to your advice (otherwise, notting changed since my previous post) ... but no change. Below, I post the log of an incoming call ... I try to call number 02xxxxx26 but I arrive on post 02xxxxx20 (central post).

 

Thank you for your help.

 

 

[5] 2011/02/04 22:49:29:

SIP Rx udp:85.119.188.3:5060:

INVITE sip:028809620@192.168.101.4:5060;transport=udp;line=c81e728d SIP/2.0

Record-Route: <sip:85.119.188.3;lr=on;ftag=as3e559475>

Via: SIP/2.0/UDP 85.119.188.3;branch=z9hG4bK4d58.fec7925.0

Via: SIP/2.0/UDP 85.119.188.67:5060;received=85.119.188.67;branch=z9hG4bK06033434;rport=5060

From: "CreaVil" <sip:02xxxxx82@85.119.188.3>;tag=as3e559475

To: <sip:02xxxxx20@85.119.188.3>

Contact: <sip:02xxxxx82@85.119.188.67>

Call-ID: 0f476e9f1dc5aa837309cd7c46ea4050@85.119.188.3

CSeq: 102 INVITE

User-Agent: Integrics Enswitch

Max-Forwards: 69

Date: Fri, 04 Feb 2011 21:49:29 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

Supported: replaces

Diversion: <sip:02xxxxx26@ast3>

Content-Type: application/sdp

Content-Length: 336

X-Enswitch-RURI: sip:02xxxxx20@85.119.188.3

X-Enswitch-Source: 85.119.188.67:5060

 

v=0

o=root 28205 28205 IN IP4 85.119.188.67

s=session

c=IN IP4 85.119.188.67

t=0 0

m=audio 16194 RTP/AVP 0 8 18 3 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:3 GSM/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=silenceSupp:off - - - -

a=ptime:20

a=sendrecv

[5] 2011/02/04 22:49:29:

Identify trunk (line match) 2

[5] 2011/02/04 22:49:29:

SIP Rx udp:85.119.188.3:5060:

INVITE sip:02xxxxx20@192.168.101.4:5060;transport=udp;line=c81e728d SIP/2.0

Record-Route: <sip:85.119.188.3;lr=on;ftag=as3e559475>

Via: SIP/2.0/UDP 85.119.188.3;branch=z9hG4bK4d58.fec7925.0

Via: SIP/2.0/UDP 85.119.188.67:5060;received=85.119.188.67;branch=z9hG4bK06033434;rport=5060

From: "CreaVil" <sip:02xxxxx82@85.119.188.3>;tag=as3e559475

To: <sip:02xxxxx20@85.119.188.3>

Contact: <sip:02xxxxx82@85.119.188.67>

Call-ID: 0f476e9f1dc5aa837309cd7c46ea4050@85.119.188.3

CSeq: 102 INVITE

User-Agent: Integrics Enswitch

Max-Forwards: 69

Date: Fri, 04 Feb 2011 21:49:29 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

Supported: replaces

Diversion: <sip:02xxxxx26@ast3>

Content-Type: application/sdp

Content-Length: 336

X-Enswitch-RURI: sip:02xxxxx20@85.119.188.3

X-Enswitch-Source: 85.119.188.67:5060

 

v=0

o=root 28205 28205 IN IP4 85.119.188.67

s=session

c=IN IP4 85.119.188.67

t=0 0

m=audio 16194 RTP/AVP 0 8 18 3 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:3 GSM/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=silenceSupp:off - - - -

a=ptime:20

a=sendrecv

[5] 2011/02/04 22:49:29:

SIP Tx udp:85.119.188.3:5060:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 85.119.188.3;branch=z9hG4bK4d58.fec7925.0

Via: SIP/2.0/UDP 85.119.188.67:5060;received=85.119.188.67;branch=z9hG4bK06033434;rport=5060

Record-Route: <sip:85.119.188.3;lr=on;ftag=as3e559475>

From: "CreaVil" <sip:02xxxxx82@85.119.188.3>;tag=as3e559475

To: <sip:02xxxxx20@85.119.188.3>;tag=d328767900

Call-ID: 0f476e9f1dc5aa837309cd7c46ea4050@85.119.188.3

CSeq: 102 INVITE

Content-Length: 0

 

[6] 2011/02/04 22:49:29:

Sending RTP for 0f476e9f1dc5aa837309cd7c46ea4050@85.119.188.3 to 85.119.188.67:16194, codec not set yet

[5] 2011/02/04 22:49:29:

Global trunk 3StarsNet@sip.somewhere.com sends call to 20 in domain sip.somewhere.com

[5] 2011/02/04 22:49:29:

SIP Tx udp:192.168.101.227:5060:

INVITE sip:20@192.168.101.227:5060;line=b9vidtev SIP/2.0

Via: SIP/2.0/UDP 192.168.101.4:5060;branch=z9hG4bK-ec930f6b4be97ba3e6f72349f0b3816e;rport

From: "CreaVil" <sip:02xxxxx82@sip.somewhere.com;user=phone>;tag=11221

To: "info@somewhere.com" <sip:20@sip.somewhere.com>

Call-ID: 95089ebe@pbx

CSeq: 15824 INVITE

Max-Forwards: 70

Contact: <sip:20@192.168.101.4:5060;transport=udp>

Supported: 100rel, replaces, norefersub

Allow-Events: refer

Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE

Accept: application/sdp

User-Agent: snom-PBX/2011-4.2.0.3981

Alert-Info: <http://127.0.0.1/Bellcore-dr3>

Content-Type: application/sdp

Content-Length: 329

 

v=0

o=- 12390 12390 IN IP4 192.168.101.4

s=-

c=IN IP4 192.168.101.4

t=0 0

m=audio 57282 RTP/AVP 0 8 9 2 3 101

a=rtpmap:0 pcmu/8000

a=rtpmap:8 pcma/8000

a=rtpmap:9 g722/8000

a=rtpmap:2 g726-32/8000

a=rtpmap:3 gsm/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtcp-xr:rcvr-rtt=all voip-metrics

a=sendrecv

[5] 2011/02/04 22:49:30:

SIP Rx udp:192.168.101.227:5060:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 192.168.101.4:5060;branch=z9hG4bK-ec930f6b4be97ba3e6f72349f0b3816e;rport=5060

From: "CreaVil" <sip:02xxxxx82@sip.somewhere.com;user=phone>;tag=11221

To: "info@somewhere.com" <sip:20@sip.somewhereco.m>;tag=6rmzq06iwa

Call-ID: 95089ebe@pbx

CSeq: 15824 INVITE

Contact: <sip:20@192.168.101.227:5060;line=b9vidtev>;reg-id=1

Require: 100rel

RSeq: 1

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE

Allow-Events: talk, hold, refer, call-info

Content-Length: 0

 

[5] 2011/02/04 22:49:30:

SIP Tx udp:192.168.101.227:5060:

PRACK sip:20@192.168.101.227:5060;line=b9vidtev SIP/2.0

Via: SIP/2.0/UDP 192.168.101.4:5060;branch=z9hG4bK-09b1b968faa0b20732bce56abebe4291;rport

From: "CreaVil" <sip:028809582@sip.somewhere.com;user=phone>;tag=11221

To: "info@somewhere.com" <sip:20@sip.somewhere.com>;tag=6rmzq06iwa

Call-ID: 95089ebe@pbx

CSeq: 15825 PRACK

Max-Forwards: 70

Contact: <sip:20@192.168.101.4:5060;transport=udp>

RAck: 1 15824 INVITE

Content-Length: 0

 

[6] 2011/02/04 22:49:30:

Codec pcmu/8000 is chosen for call id 0f476e9f1dc5aa837309cd7c46ea4050@85.119.188.3

[5] 2011/02/04 22:49:30:

SIP Tx udp:85.119.188.3:5060:

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP 85.119.188.3;branch=z9hG4bK4d58.fec7925.0

Via: SIP/2.0/UDP 85.119.188.67:5060;received=85.119.188.67;branch=z9hG4bK06033434;rport=5060

Record-Route: <sip:85.119.188.3;lr=on;ftag=as3e559475>

From: "CreaVil" <sip:02xxxxx82@85.119.188.3>;tag=as3e559475

To: <sip:02xxxxx20@85.119.188.3>;tag=d328767900

Call-ID: 0f476e9f1dc5aa837309cd7c46ea4050@85.119.188.3

CSeq: 102 INVITE

Contact: <sip:028809620@192.168.101.4:5060;transport=udp>

Supported: 100rel, replaces, norefersub

Allow-Events: refer

Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE

Accept: application/sdp

User-Agent: snom-PBX/2011-4.2.0.3981

Content-Type: application/sdp

Content-Length: 290

 

v=0

o=- 46234 46234 IN IP4 192.168.101.4

s=-

c=IN IP4 192.168.101.4

t=0 0

m=audio 53932 RTP/AVP 0 8 3 101

a=rtpmap:0 pcmu/8000

a=rtpmap:8 pcma/8000

a=rtpmap:3 gsm/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

a=rtcp-xr:rcvr-rtt=all voip-metrics

a=sendrecv

[5] 2011/02/04 22:49:30:

SIP Rx udp:192.168.101.227:5060:

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 192.168.101.4:5060;branch=z9hG4bK-09b1b968faa0b20732bce56abebe4291;rport=5060

From: "CreaVil" <sip:02xxxxx82@sip.somewhere.com;user=phone>;tag=11221

To: "info@somewhere.com" <sip:20@sip.somewhere.com>;tag=6rmzq06iwa

Call-ID: 95089ebe@pbx

CSeq: 15825 PRACK

Contact: <sip:20@192.168.101.227:5060;line=b9vidtev>;reg-id=1

Content-Length: 0

[Vodia PBX]

I assume the problem is the following: You register the trunk, and the PBX registers the contact xxx20@yyy. Now when the provider wants to send you a call, it sends it to xxx20@yyy, which is absolutely correct and the only way which corresponds to the RFC.

 

Now here comes the tricky question. How can the PBX know which number was called? It cannot be found in the Reqest-URI (which is what the RFC says); instead you'll find it in the To-Header (see http://wiki.snomone.com/index.php?title=Inbounds_Calls). For example, when you use the following pattern, it should take the last two digits from the To-Header and try to route it there, and if it was not found route it to 20: "!([0-9]{2})$!\1!t!20!" (notice the t in between all those exclamation marks which means take the number out of the To-Header URI). ERE are ugly, but flexible and this way it should be possible to have the PBX route the call where it should go.

[pbx support]

The PBX receives the INVITE as

INVITE sip:028809620@192.168.101.4:5060;transport=udp;line=c81e728d SIP/2.0

Are you sure you are dialing 02xxxxx26 ?

[Dimitri]

Thanks for the response.

 

Indeed ... I'm dialing 02xxxxx26! The number isn't found in the To header ... But in "Diversion: <sip:02xxxxx26@ast2>". How can I filter on this? The script you gave me doesn't change a thing.

 

Thanks in advance.

D

[pbx support]

I see. The PBX does not make use of Diversion header. It makes use of either request URI (the 1st line) or the "To" field to route the call. So if the provider can send the number in the request URI or the To field, then you can send the call to the proper extensions.