Inbound DID routing

[jlag]

My SIP Invite:

INVITE sip:[email protected]:5060;rinstance=084eee3438cc22fb;received=10.112.189.140:5060

Here my DID is clearly before the destination IP Address, "INVITE SIPID@IP:5060;"

In the Provider Source ID tab:
I have checked the "Source indentification by DID" box,
Selected: "Request Line URI : User Part" as the "SIP Field containing DID numbers",
added masks for the DID's such as:
4124992700
4124992701
4124992702

Then added the DID's to the DID tab in the Edit VOIP Provider.

Calls still only route to the destination setup under the "Edit VOIP Provider" screen, no matter the routing on the spific DID's further down the tree.
I have also tried setting the fields ReqLineURI : User Part to Line ID and Line Number on the Edit Voip Provider screen to no avail.

Followed this link as well:
http://support.orbtalk.co.uk/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=32

I have searched quite a few posts and have not been able to solve this as of yet. Any ideas appreciated.

 

[abc123]

Where are you seeing that invite string? That is not a correct rfc 3261 invite request format.

it should say
INVITE sip:4124992700@ipaddressort SIP/2.0

That the request uri is the sip:did@iport part and you have asked 3cx to strip "sip:" and use everything in the did part (before the @). But either it couldnt parse it correctly as it is not a recognized invite format or you are not showing the information 3cx is receiving.

Can you get the invite from 3cx? You may have to turn on verbose logging and restart it.

 

[jlag]

Here is the string from verbose:

INVITE sip:[email protected]:5060;rinstance=047a6e2738bb79fe;received=10.112.189.140:5060
SIP/2.0..Record-Route: <sipb2proxy-pro-aws03.phoneboothdev.info;lr=on;did=ccd.a5c00f51>..
Via: SIP/2.0/UDP pb2proxy-pro-aws03.phoneboothdev.info;branch=z9hG4bK4823.05395b33.0..

This is a FreePBX.org trunk.

Good news is I got my Soundwin S400 Gateway/ATA working with the PBX. 2FXS,2FXO. I can connect my ATT 1A2 Key System to VOIP now

 

[SY]

Even basic level of log may explain something.
Could you please post it?

Thanks

 

[abc123]

You didnt post the full invite message (contact? from? to? - we need those to help you)

I dont know how 3cx will handle that invite request uri

If it cannot parse it then we need to use the other information that you left out.

If it does parse it then you should be able to set the source id to request uri user part (this is the 4124992702) so add that did to the did tab and select DID from the source id tab (have to add the dids first) and select all.

Then you will see the dids under the main provider in the left menu. Click on them there or in the inbound rules and then you can route them.

 

[jlag]

All seems normal, just didn't route to DR, went to RG, which is setup for the root DID in the tree under the voip provider.
Does not complain about Source ID.

15:48:19.600  [CM503008]: Call(6): Call is terminated
15:48:07.393  Session 687 of leg C:6.1 is confirmed
15:48:07.302  [CM503007]: Call(6): Device joined: sip:[email protected]:49184;transport=udp
15:48:07.282  [CM503007]: Call(6): Device joined: sip:[email protected]:5060
15:48:07.282  [MS210003] C:6.1:Answer provided. Connection(transcoding mode[unsecure]):173.74.244.118:9006(9007)
15:48:07.282  [MS210001] C:6.2:Answer received. RTP connection[unsecure]: 172.16.0.93:21000(21001)
15:48:07.272  Remote SDP is set for legC:6.2
15:48:07.272  [CM505001]: Ext.2345: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Sipdroid/2.1 beta/DROID PRO] PBX contact: [sip:[email protected]:5060]
15:48:07.272  [CM503002]: Call(6): Alerting sip:[email protected]:49184;transport=udp
15:48:04.749  [CM503025]: Call(6): Calling Ring12468:2345Ext.23452346Ext.23462399Ext.2399@[Dev:sip:[email protected]:49184;transport=udp]
15:48:04.749  [MS210002] C:6.2:Offer provided. Connection(transcoding mode): 172.16.0.120:7014(7015)
15:48:04.719  [CM503004]: Call(6): Route 1: Ring12468:2345Ext.23452346Ext.23462399Ext.2399@[Dev:sip:[email protected]:49184;transport=udp]
15:48:04.709  [CM503010]: Making route(s) to <sip:[email protected]:5060>
15:48:04.709  [MS210000] C:6.1:Offer received. RTP connection: 67.231.8.106:15192(15193)
15:48:04.709  Remote SDP is set for legC:6.1
15:48:04.709  [CM505003]: Provider:[FreePBX] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [FreeSWITCH-mod_sofia/1.0.4-exported] PBX contact: [sip:[email protected]:5060]
15:48:04.699  [CM503001]: Call(6): Incoming call from +15096226100@(Ln.10002@FreePBX) to <sip:[email protected]:5060>
15:48:04.598  [CM503012]: Inbound out-of-office hours rule (unnamed) for 10002 forwards to DN:2468
15:48:04.598  Looking for inbound target: called=7243eb65; caller=+15096226100
15:48:04.588  [CM500002]: Info on incoming INVITE:
  INVITE sip:[email protected]:5060;rinstance=29bc5aafd1439f08;received=10.112.189.140:5060 SIP/2.0
  Via: SIP/2.0/UDP pb2proxy-pro-aws03.phoneboothdev.info;branch=z9hG4bKec47.3b5dd4b2.0;received=184.72.227.214
  Via: SIP/2.0/UDP 10.110.26.133;received=10.110.26.133;rport=5060;branch=z9hG4bKp0NUaNXc8rZXj
  Max-Forwards: 50
  Record-Route: <sip:pb2proxy-pro-aws03.phoneboothdev.info;lr=on;did=dfd.63526ba1>
  Contact: <sip:[email protected]:5060>
  To: <sip:[email protected]:5060;rinstance=23bc5aafd4439ff8;received=10.112.189.140:5060>
  From: "+15096226100"<sip:[email protected]>;tag=eUD90pNytycjm
  Call-ID: 8f0e4534-c143-122e-65a9-1231391c1c77
  CSeq: 9299781 INVITE
  Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO
  Supported: precondition, path, replaces
  User-Agent: FreeSWITCH-mod_sofia/1.0.4-exported
  Allow-Events: talk, refer
  Privacy: none
  P-Asserted-Identity: "+15096226100" <sip:[email protected]>
  Content-Length: 0
  
15:48:02.075  Currently active calls [none]
15:47:31.972  Currently active calls [none]
15:47:01.858  Currently active calls [none]
15:46:31.815  Currently active calls [none]

 

[abc123]

Can you confirm the following?

On the edit voip provider DID tab you have the did in the form 4124992702?

Then on the Source ID tab you have the Source identification by DID checked.

The Sip Field containing DID numbers is Request Line URI: User Part

and Source Identification by DID should click the Add DID and then select all so the box fills with your DIDs.

Then click ok.

Then go to your inbound rules and choose the 2702 did and choose the route.

Then ok

then test.

 

[SY]

INVITE sip:[email protected]:5060;rinstance=29bc5aafd1439f08;received=10.112.189.140:5060 SIP/2.0
Via: SIP/2.0/UDP pb2proxy-pro-aws03.phoneboothdev.info;branch=z9hG4bKec47.3b5dd4b2.0;received=184.72.227.214
Via: SIP/2.0/UDP 10.110.26.133;received=10.110.26.133;rport=5060;branch=z9hG4bKp0NUaNXc8rZXj
To: <sip:[email protected]:5060;rinstance=23bc5aafd4439ff8;received=10.112.189.140:5060>
From: "+15096226100"<sip:[email protected]>
Record-Route: <sipb2proxy-pro-aws03.phoneboothdev.info;lr=on;did=dfd.63526ba1>

I dont believe that it is the native FreePBX.org... Too many things which are really strange...

 

[jlag]

I am really not testing you. That is a SIPStation.com trunk from FreePBX.

They had a bug with outbound caller ID last week, They pushed a dev build up on Monday of this week that corrected it, maybe they left some test stuff in there accidentally?

 

[abc123]

INVITE sip:[email protected]:5060;rinstance=29bc5aafd1439f08;received=10.112.189.140:5060 SIP/2.0
Via: SIP/2.0/UDP pb2proxy-pro-aws03.phoneboothdev.info;branch=z9hG4bKec47.3b5dd4b2.0;received=184.72.227.214
Via: SIP/2.0/UDP 10.110.26.133;received=10.110.26.133;rport=5060;branch=z9hG4bKp0NUaNXc8rZXj
To: <sip:[email protected]:5060;rinstance=23bc5aafd4439ff8;received=10.112.189.140:5060>
From: "+15096226100"<sip:[email protected]>
Record-Route: <sipb2proxy-pro-aws03.phoneboothdev.info;lr=on;did=dfd.63526ba1>

I dont believe that it is the native FreePBX.org... Too many things which are really strange...

Stepan

Can 3cx parse this Request URI with all the extras in there? The user part would pull out if you are parsing just the first part.

His logs look like they didnt pull it out (and are looking for the To user part?)

 

[jlag]

Can you confirm the following?

On the edit voip provider DID tab you have the did in the form 4124992702?

Then on the Source ID tab you have the Source identification by DID checked.

The Sip Field containing DID numbers is Request Line URI: User Part

and Source Identification by DID should click the Add DID and then select all so the box fills with your DIDs.

Then click ok.

Then go to your inbound rules and choose the 2702 did and choose the route.

Then ok

then test.

On the voip provider tab I have DID 4124992700 in the Port Identification field, and selected to route to Ring Group for office hours, then "same as during office hours" is checked.
Under General Tab I have 4124992700 as the External Number field.
Under Source ID Tab I have ID By DID checked, Request Line URI :User Part and have the three DID's in the list box:
4124992700,
4124992701,
4124992702
Then under Inbound Rules, I have 2700, to ring group, 2701 and 2702 to DR. Outside Office Hours is checked for all three rules.
All inbound still routes to Ring Group.
inbound always goes to what is selected in the root of the DID tree for the provider, even if all of the inbound rules are set to something else. For instance, if I route the root of the DID tree to the DR and the rest to the ring group, all inbound routes to the DR.

 

[jlag]

Here is a log from a DID from the same provider that is not configured as a DID in 3CX, it could not route. So it seems part of the code is parsing the DID string from the INVITE:

17:16:46.411  [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification:
  INVITE sip:[email protected]:5060;rinstance=c64e4abed6041c72;received=10.112.189.140:5060 SIP/2.0
  Via: SIP/2.0/UDP pb2proxy-pro-aws03.phoneboothdev.info;branch=z9hG4bK5d0e.5a1871d3.0;received=184.72.227.214
  Via: SIP/2.0/UDP 10.110.26.133;received=10.110.26.133;rport=5060;branch=z9hG4bKmmS1U9Xa3N8XB
  Max-Forwards: 50
  Record-Route: <sip:pb2proxy-pro-aws03.phoneboothdev.info;lr=on;did=f2c.cc803c33>
  Contact: <sip:[email protected]:5060>
  To: <sip:[email protected]:5060;rinstance=c64e4abed6041c72;received=10.112.189.140:5060>
  From: "+15086532513"<sip:[email protected]>;tag=2HXFUt3jBSgra
  Call-ID: f361dc75-c14f-122e-65a9-1231391c1c77
  CSeq: 9302442 INVITE
  Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO
  Supported: precondition, path, replaces
  User-Agent: FreeSWITCH-mod_sofia/1.0.4-exported
  Allow-Events: talk, refer
  Privacy: none
  P-Asserted-Identity: "+15086532513" <sip:[email protected]>
  Content-Length: 0
  
17:16:46.411  [CM302001]: Authorization system can not identify source of: SipReq:  INVITE [email protected]:5060 tid=5d0e.5a1871d3.0 cseq=INVITE [email protected]:5060 / 9302442 from(wire)
17:16:45.930  Currently active calls [none]
17:16:15.887  Currently active calls [none]

 

[abc123]

It looks correct

Double check your inbound rules in case the accidentally changed or didnt save.

Other than that the only explanation is that is it a horribly formed request and 3cx is having problems with it.

 

[jlag]

It is pretty odd.

I have another VOIP provider that I can add a second DID too just for sanity. I also have an Asterisk PBX at a job site that I can run some outbound request into 3CX from. I have a VOIP provider setup in 3CX that is an extension on that Astrisk PBX already.

Worst case, I'll write a 'quick' app that grabs that frame, reformats it and sends it to 3CX. Of course once I do that they will fix the header!

Do you think I should a put a question into FreePBX regarding that INVITE request format?

 

[abc123]

Be careful about rewriting sip messages and headers unless you know what you are doing. I speak from experience as I have just written our own Sip Stack and it is complex when you take the dialogs etc into account.

I wouldnt go to freepbx it is not them, it is how your voip provider has done it.

I would contact them and get them to fix it. You say they have put a developer build on it, then they need to fix it and take off the extras they have added for tracing some problems.

 

[jlag]

I have fooled around with some heavy protocols for process control, Foundation Fieldbus, MMS. Its all fun, its what I do for a living.

FreePBX.org is where the support questions go for the SIPStation trunks.

I can use FreePBX.com or Phonebooth.net as the SIP Server to register with.

http://www.sipstation.com/ -FreePBX trunks.

 

[abc123]

Someone somewhere is messing with the request so yes contact who ever you need to.

 

[jlag]

The strings from my asterisk PBX and from VOIPVOIP do not have the extra:

received=10.112.189.140:5060


garbage along with some other stuff (you guys already knew that). We'll see what they say.

 

[SY]

Can 3cx parse this Request URI with all the extras in there? The user part would pull out if you are parsing just the first part.

Additional parametes of URI is not a problem at all. All headers are well-formed but content is amazing.

His logs look like they didnt pull it out (and are looking for the To user part?)

"CalledNum" is taken as specified by inbound parameters. Source identification settings don't alter it.

It is pretty odd.

Completelly agree.
Such cryptic content of INVITE request requires adjustment of "source indentification" AND "inbound parameters".

Worst case, I'll write a 'quick' app that grabs that frame, reformats it and sends it to 3CX. Of course once I do that they will fix the header!

Do you think I should a put a question into FreePBX regarding that INVITE request format?

source identification by DID is only special case of source identification. It doesn't influence initialization of inbound parameters.

It is not necessary to write a 'quick' app.
by default, "CalledNum" inbound parameter is taken from the user part of "To:" header. You can alter it on "Inbound parameters" tab.

 

[jlag]

SOLVED

It is not necessary to write a 'quick' app.
by default, "CalledNum" inbound parameter is taken from the user part of "To:" header. You can alter it on "Inbound parameters" tab.

Yes, you are right SY, issue resolved, much easier than modifying the frame in my forwarder.

Changed "CalledNum" parm to pull from "Request Line URI : User Part", all fixed.

The Asterisk/FreePBX box I have along with VOIPVOIP and Vonage all send the DID in the "To:", very cleanly.

The FreePBX VOIP (it actually bandwidth.com marketed as FreePBX, with support going through FreePBX email) is putting the user/authID in the user part of the To: header, along with some other goodies it appears.

Thanks for all your time ABC and SY.

John L.