Inbound calls not routing to calling cards

633 views
Skip to first unread message

Steve

unread,
May 30, 2016, 7:04:50 PM5/30/16
to ASTPP
Hi,

I have looked at the posts relating to this but I can't figure out what to do ... I want an incoming call from my provider to go to the calling card system.  The only docs I can find are how to bridge the call to an extension.  How do you tell FS or ASTPP to send the call to the CC system?

Thanks,
Steve

Hardik Patel

unread,
May 31, 2016, 12:07:21 AM5/31/16
to as...@googlegroups.com
Hi Steve,

For callingcard you need to add that DID number under the access number field.
You can find that field under

BASE_URL/systems/configuration/callingcard
Field Name :

Please add your DID number under this field and check.

Thanks,
Hardik Patel
iNextrix Technologies Pvt Ltd.
www.inextrix.com


--
=====================================================================
Documentation : https://astppdoc.atlassian.net/
Please contact at sa...@inextrix.com for commercial support.
---
You received this message because you are subscribed to the Google Groups "ASTPP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astpp+un...@googlegroups.com.
To post to this group, send email to as...@googlegroups.com.
Visit this group at https://groups.google.com/group/astpp.
To view this discussion on the web visit https://groups.google.com/d/msgid/astpp/825ccd5b-71ec-411b-99f3-b6f7393b3ec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Steve

unread,
May 31, 2016, 4:58:26 AM5/31/16
to ASTPP
Thanks for your response.  Yes I've tried that but then I get ACL errors and I've read everything I can about acl but I don't see why it would reject anything from a reged gateway.  This example is the best I've found:

<extension name="Voicepulse">   <!-- your provider or any name you'd like to call it -->
    <condition field="destination_number" expression="15555551212">  <!-- your DID for this gateway-->
     <action application="transfer" data="1001 XML default"/>
    </condition>
   </extension>

But I don't want to transfer to an extension, I want it to go into ASTPP.  Do I have play with the ACL which is rejecting the calls?  I have found very little on this on FS docs.
Thanks,
Steev

Fozzy

unread,
May 31, 2016, 5:07:34 AM5/31/16
to ASTPP
Hi Steve,

Looks like you need to add the IP of your provider the the ACL list. Go to Accounts > Customers, edit your provider and add their IP/s to the IP Settings list.

Steve

unread,
May 31, 2016, 5:19:47 AM5/31/16
to ASTPP
This is what I get in the CLI when I call the DID:

2016-05-31 01:18:44.815349 [DEBUG] switch_core_state_machine.c:543 (sofia/external/65079...@75.127.65.130) Running State Change CS_NEW
2016-05-31 01:18:44.815349 [DEBUG] sofia.c:9376 sofia/external/65079...@75.127.65.130 receiving invite from 75.127.65.130:5060 version: 1.6.8 git 99de0ad 2016-05-05 15:38:32Z 64bit
2016-05-31 01:18:44.815349 [WARNING] sofia.c:9536 IP 75.127.65.130 Rejected by acl "default"
2016-05-31 01:18:44.815349 [DEBUG] switch_core_state_machine.c:562 (sofia/external/65079...@75.127.65.130) State NEW
2016-05-31 01:18:44.815349 [NOTICE] sofia.c:2212 Hangup sofia/external/65079...@75.127.65.130 [CS_NEW] [CALL_REJECTED]
2016-05-31 01:18:44.835359 [DEBUG] sofia.c:1419 Channel is already hungup.


On Monday, May 30, 2016 at 7:04:50 PM UTC-4, Steve wrote:

Steve

unread,
May 31, 2016, 7:03:40 AM5/31/16
to ASTPP
Thanks Fozzy ... that's what I've been trying to figure out.  So ASTPP is controlling the "default" acl it seems.  But now it still won't answer my incoming calls because (at least in FS) it doesn't pass the DID number ... asterisk does this fine with the same provider.  Scratching my head.  

Steve

unread,
May 31, 2016, 7:05:56 AM5/31/16
to ASTPP
Well nevermind partly Fozzy's post on allowing IPs in customer section worked great, but now it doesn't recognize the DID number ... it just spits out a string of digits and of course FS declines the call.  In asterisk the DID number always shows up.  I don't know what's wrong here.


On Monday, May 30, 2016 at 7:04:50 PM UTC-4, Steve wrote:

Fozzy

unread,
May 31, 2016, 7:19:02 AM5/31/16
to ASTPP
Are you using "local" as your call type in DID setting? if so then there is a hack in one of the files you need to apply. Else if your Asterisk is connected from a fixed IP then you can use the "Other" option and route the calls using the following string:

sofia/default/12...@1.1.1.1

1234 being the DID and 1.1.1.1 the IP of the asterisk PBX.


On Tuesday, 31 May 2016 01:04:50 UTC+2, Steve wrote:

Mister Woose

unread,
May 31, 2016, 7:37:29 AM5/31/16
to as...@googlegroups.com
I'm not using a dial string that I know of ... it's just a DID coming in from my provider.  I'm not using an asterisk box for ASTPP, but it sure would be easire :)  And where do you find "local" call type in DID setting?
--
=====================================================================
Documentation : https://astppdoc.atlassian.net/
Please contact at sa...@inextrix.com for commercial support.
---
You received this message because you are subscribed to a topic in the Google Groups "ASTPP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/astpp/l8K73Jb-KNk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to astpp+un...@googlegroups.com.

To post to this group, send email to as...@googlegroups.com.
Visit this group at https://groups.google.com/group/astpp.

Fozzy

unread,
May 31, 2016, 10:14:17 AM5/31/16
to ASTPP
Hi Steve,

Ok I'm assuming you using ASTPP as your billing / calling card system. If its a calling card then you have your customers SIP phones connecting directly to the ASTPP server right? Else you have a PBX (like Asterisk) connecting to ASTPP via a SIP trunk.

If its a direct phone then in your DID settings in ASTPP you have a DID number from your provider that you sell or assign to a customer. (Im not sure how it works for calling card as I have never used it)

In the DID setup window there is a section called DID Settings. There is a drop down with options PSTN, Local and Other. PSTN is for transferring or forwarding calls to another PSTN or provider, Local is for the SIP device you setup for your customer and Other is how you construct your own dial strings to do your own fancy routing.

If your customers phone registers with ASTPP on the SIP device then you would us Local option. The same applies to Asterisk but if you want the DID to precent to asterisk using the local option, there is a bit of code to change in ASTPP xml files. (This has been reported and requested to change but I still see it has not been done in the latest release) If you use the option of other and the string I provided earlier then you are routing calls directly to the DID and IP of the PBX or phone.

I hope this helps.


On Tuesday, 31 May 2016 13:37:29 UTC+2, Steve wrote:
I'm not using a dial string that I know of ... it's just a DID coming in from my provider.  I'm not using an asterisk box for ASTPP, but it sure would be easire :)  And where do you find "local" call type in DID setting?


On 5/31/2016 7:19 AM, Fozzy wrote:
Are you using "local" as your call type in DID setting? if so then there is a hack in one of the files you need to apply. Else if your Asterisk is connected from a fixed IP then you can use the "Other" option and route the calls using the following string:


1234 being the DID and 1.1.1.1 the IP of the asterisk PBX.

On Tuesday, 31 May 2016 01:04:50 UTC+2, Steve wrote:
Hi,

I have looked at the posts relating to this but I can't figure out what to do ... I want an incoming call from my provider to go to the calling card system.  The only docs I can find are how to bridge the call to an extension.  How do you tell FS or ASTPP to send the call to the CC system?

Thanks,
Steve

Mister Woose

unread,
May 31, 2016, 11:52:38 AM5/31/16
to as...@googlegroups.com
Hi Fozzy,

Thanks for your well-written reply.  I'm trying to use FS and ASTPP to provide a general access number where the customer can enter their PIN and make calls.  Of course they can use SIP as well.  I don't want to sell DID's to customers ... I just want to provide an access number they can dial into and access the calling card system.  I wan't planning to use Asterisk, but that may be the only way :)

Thanks again for your help.

Regards,
Steve

Samir Doshi

unread,
May 31, 2016, 2:27:44 PM5/31/16
to ASTPP
If you simply want to make calling card working then you doesn't need to create DID number in DID module but rather you need to configure calling card DID number / access number in cc access number field of global configuration. 
Also do not forget to add your provider IP under ACL list from your customer / provider IP MAP module or by creating gateway with provider IP. 

Once done, call your access number from your cell phone and check freeswitch logs. It should try to build calling card dialplan and execute it. 

Important Note : To execute calling card flow, you must have mod_perl module loaded in freeswitch. 



Best Regards
--
Samir Doshi
iNextrix Technologies Pvt. Ltd.
http://www.inextrix.com



Disclaimer:
The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.

You received this message because you are subscribed to the Google Groups "ASTPP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astpp+un...@googlegroups.com.

To post to this group, send email to as...@googlegroups.com.
Visit this group at https://groups.google.com/group/astpp.

Mister Woose

unread,
May 31, 2016, 9:02:39 PM5/31/16
to as...@googlegroups.com
Thank you very much Samir,

Thanks very much for the helpful info ... I will try that and hopefully achieve success! 

Regards,
Steve

Mister Woose

unread,
Jun 1, 2016, 6:22:40 AM6/1/16
to as...@googlegroups.com
Thank very much Samir.  I think I understand how the system works now.  I'm re-installing on a Droplet to see what happens :)


Regards,
Steve

On 5/31/2016 2:27 PM, Samir Doshi wrote:

Mister Woose

unread,
Jun 2, 2016, 6:40:19 AM6/2/16
to as...@googlegroups.com
I installed ASTPP again and things are sort of working.  I have the IP auth set in gateway settings (there was no choice the dro-down box for the customer IP.)  But it's accepting the call, it just thinks my account number is the DID and is prepending 00 before my account number.  I have it set in the calling card config.  I don't see where FS receives the DID info to know how to route it.

2016-06-02 06:32:41.656502 [INFO] mod_dptools.c:1713 [Customer info] : [Account code: 1956333338, Rategroup Id: 1, Called number: 116412_88]
EXECUTE sofia/external/65079...@107.6.67.237 set(origination_rates=ID:9202|CODE:^1.*|DESTINATION:United States|CONNECTIONCOST:0.00240|INCLUDEDSECONDS:12|COST:0.02400|INC:6|RATEGROUP:1|MARKUP:0|ACCID:4)
2016-06-02 06:32:41.656502 [DEBUG] mod_dptools.c:1519 SET sofia/external/65079...@107.6.67.237 [origination_rates]=[ID:9202|CODE:^1.*|DESTINATION:United States|CONNECTIONCOST:0.00240|INCLUDEDSECONDS:12|COST:0.02400|INC:6|RATEGROUP:1|MARKUP:0|ACCID:4]
EXECUTE sofia/external/65079...@107.6.67.237 set(effective_destination_number=116412_88)
2016-06-02 06:32:41.656502 [DEBUG] mod_dptools.c:1519 SET sofia/external/65079...@107.6.67.237 [effective_destination_number]=[116412_88]
EXECUTE sofia/external/65079...@107.6.67.237 set(termination_rates=ID:9201|CODE:^1.*|DESTINATION:United States|CONNECTIONCOST:0.00100|INCLUDEDSECONDS:6|COST:0.01000|INC:6|TRUNK:2|PROVIDER:4)
2016-06-02 06:32:41.656502 [DEBUG] mod_dptools.c:1519 SET sofia/external/65079...@107.6.67.237 [termination_rates]=[ID:9201|CODE:^1.*|DESTINATION:United States|CONNECTIONCOST:0.00100|INCLUDEDSECONDS:6|COST:0.01000|INC:6|TRUNK:2|PROVIDER:4]
EXECUTE sofia/external/65079...@107.6.67.237 bridge(sofia/gateway/Voipms/00116412_88)
2016-06-02 06:32:41.656502 [DEBUG] switch_ivr_originate.c:2127 Parsing global variables
2016-06-02 06:32:41.656502 [NOTICE] switch_channel.c:1104 New Channel sofia/external/00116412_88 [b156ea9d-fefb-46af-a81f-b9249a1a32ea]
2016-06-02 06:32:41.656502 [DEBUG] mod_sofia.c:4813 (sofia/external/00116412_88) State Change CS_NEW -> CS_INIT
2016-06-02 06:32:41.656502 [DEBUG] switch_core_state_machine.c:543 (sofia/external/00116412_88) Running State Change CS_INIT
2016-06-02 06:32:41.656502 [DEBUG] switch_core_state_machine.c:586 (sofia/external/00116412_88) State INIT
2016-06-02 06:32:41.656502 [DEBUG] mod_sofia.c:89 sofia/external/00116412_88 SOFIA INIT
2016-06-02 06:32:41.656502 [DEBUG] sofia_glue.c:1228 sip:newyork3.voip.ms Setting proxy route to sofia/external/00116412_88
2016-06-02 06:32:41.656502 [DEBUG] sofia_glue.c:1257 sofia/external/00116412_88 sending invite version: 1.6.8 git 99de0ad 2016-05-05 15:38:32Z 64bit
Local SDP:
v=0
o=FreeSWITCH 1464840925 1464840926 IN IP4 107.170.68.211
s=FreeSWITCH
c=IN IP4 107.170.68.211
t=0 0
m=audio 22636 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:40 sofia/external/00116412_88 Standard INIT
2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:48 (sofia/external/00116412_88) State Change CS_INIT -> CS_ROUTING
2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:586 (sofia/external/00116412_88) State INIT going to sleep
2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:543 (sofia/external/00116412_88) Running State Change CS_ROUTING
2016-06-02 06:32:41.676497 [DEBUG] sofia.c:6858 Channel sofia/external/00116412_88 entering state [calling][0]
2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:602 (sofia/external/00116412_88) State ROUTING
2016-06-02 06:32:41.676497 [DEBUG] mod_sofia.c:142 sofia/external/00116412_88 SOFIA ROUTING
2016-06-02 06:32:41.676497 [DEBUG] switch_ivr_originate.c:67 (sofia/external/00116412_88) State Change CS_ROUTING -> CS_CONSUME_MEDIA
2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:602 (sofia/external/00116412_88) State ROUTING going to sleep
2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:543 (sofia/external/00116412_88) Running State Change CS_CONSUME_MEDIA
2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:621 (sofia/external/00116412_88) State CONSUME_MEDIA
2016-06-02 06:32:41.676497 [DEBUG] switch_core_state_machine.c:621 (sofia/external/00116412_88) State CONSUME_MEDIA going to sleep
2016-06-02 06:32:41.716523 [DEBUG] sofia.c:6858 Channel sofia/external/00116412_88 entering state [calling][0]
2016-06-02 06:32:41.716523 [DEBUG] sofia.c:6858 Channel sofia/external/00116412_88 entering state [terminated][404]
2016-06-02 06:32:41.716523 [NOTICE] sofia.c:7881 Hangup sofia/external/00116412_88 [CS_CONSUME_MEDIA] [UNALLOCATED_NUMBER]
2016-06-02 06:32:41.716523 [DEBUG] switch_core_state_machine.c:543 (sofia/external/00116412_88) Running State Change CS_HANGUP
2016-06-02 06:32:41.716523 [DEBUG] switch_core_state_machine.c:809 (sofia/external/00116412_88) Callstate Change DOWN -> HANGUP
2016-06-02 06:32:41.716523 [DEBUG] switch_core_state_machine.c:811 (sofia/external/00116412_88) State HANGUP
2016-06-02 06:32:41.716523 [DEBUG] mod_sofia.c:437 Channel sofia/external/00116412_88 hanging up, cause: UNALLOCATED_NUMBER
2016-06-02 06:32:41.716523 [DEBUG] switch_core_state_machine.c:60 sofia/external/00116412_88 Standard HANGUP, cause: UNALLOCATED_NUMBER
2016-06-02 06:32:41.716523 [DEBUG] switch_core_state_machine.c:811 (sofia/external/00116412_88) State HANGUP going to sleep
2016-06-02 06:32:41.716523 [DEBUG] switch_core_state_machine.c:578 (sofia/external/00116412_88) State Change CS_HANGUP -> CS_REPORTING
2016-06-02 06:32:41.716523 [DEBUG] switch_core_state_machine.c:543 (sofia/external/00116412_88) Running State Change CS_REPORTING
2016-06-02 06:32:41.716523 [DEBUG] switch_core_state_machine.c:897 (sofia/external/00116412_88) State REPORTING
2016-06-02 06:32:41.736502 [DEBUG] switch_ivr_originate.c:3750 Originate Resulted in Error Cause: 1 [UNALLOCATED_NUMBER]
2016-06-02 06:32:41.736502 [INFO] mod_dptools.c:3401 Originate Failed.  Cause: UNALLOCATED_NUMBER
2016-06-02 06:32:41.736502 [NOTICE] switch_core_state_machine.c:385 sofia/external/65079...@107.6.67.237 has executed the last dialplan instruction, hanging up.
2016-06-02 06:32:41.736502 [NOTICE] switch_core_state_machine.c:387 Hangup sofia/external/65079...@107.6.67.237 [CS_EXECUTE] [NORMAL_CLEARING]
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:609 (sofia/external/65079...@107.6.67.237) State EXECUTE going to sleep
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:543 (sofia/external/65079...@107.6.67.237) Running State Change CS_HANGUP
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:809 (sofia/external/65079...@107.6.67.237) Callstate Change RINGING -> HANGUP
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:811 (sofia/external/65079...@107.6.67.237) State HANGUP
2016-06-02 06:32:41.736502 [DEBUG] mod_sofia.c:431 sofia/external/65079...@107.6.67.237 Overriding SIP cause 480 with 404 from the other leg
2016-06-02 06:32:41.736502 [DEBUG] mod_sofia.c:437 Channel sofia/external/65079...@107.6.67.237 hanging up, cause: NORMAL_CLEARING
2016-06-02 06:32:41.736502 [DEBUG] mod_sofia.c:574 Responding to INVITE with: 404
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:60 sofia/external/65079...@107.6.67.237 Standard HANGUP, cause: NORMAL_CLEARING
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:811 (sofia/external/65079...@107.6.67.237) State HANGUP going to sleep
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:578 (sofia/external/65079...@107.6.67.237) State Change CS_HANGUP -> CS_REPORTING
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:543 (sofia/external/65079...@107.6.67.237) Running State Change CS_REPORTING
2016-06-02 06:32:41.736502 [DEBUG] switch_core_state_machine.c:897 (sofia/external/65079...@107.6.67.237) State REPORTING
2016-06-02 06:32:42.196506 [DEBUG] switch_core_state_machine.c:174 sofia/external/00116412_88 Standard REPORTING, cause: UNALLOCATED_NUMBER
2016-06-02 06:32:42.196506 [DEBUG] switch_core_state_machine.c:897 (sofia/external/00116412_88) State REPORTING going to sleep
2016-06-02 06:32:42.196506 [DEBUG] switch_core_state_machine.c:569 (sofia/external/00116412_88) State Change CS_REPORTING -> CS_DESTROY
2016-06-02 06:32:42.196506 [DEBUG] switch_core_session.c:1646 Session 6 (sofia/external/00116412_88) Locked, Waiting on external entities
2016-06-02 06:32:42.196506 [NOTICE] switch_core_session.c:1664 Session 6 (sofia/external/00116412_88) Ended
2016-06-02 06:32:42.196506 [NOTICE] switch_core_session.c:1668 Close Channel sofia/external/00116412_88 [CS_DESTROY]
2016-06-02 06:32:42.196506 [DEBUG] switch_core_state_machine.c:700 (sofia/external/00116412_88) Running State Change CS_DESTROY
2016-06-02 06:32:42.196506 [DEBUG] switch_core_state_machine.c:710 (sofia/external/00116412_88) State DESTROY
2016-06-02 06:32:42.196506 [DEBUG] mod_sofia.c:342 sofia/external/00116412_88 SOFIA DESTROY
2016-06-02 06:32:42.196506 [DEBUG] switch_core_state_machine.c:181 sofia/external/00116412_88 Standard DESTROY
2016-06-02 06:32:42.196506 [DEBUG] switch_core_state_machine.c:710 (sofia/external/00116412_88) State DESTROY going to sleep
2016-06-02 06:32:42.216503 [DEBUG] switch_core_state_machine.c:174 sofia/external/65079...@107.6.67.237 Standard REPORTING, cause: NORMAL_CLEARING
2016-06-02 06:32:42.216503 [DEBUG] switch_core_state_machine.c:897 (sofia/external/65079...@107.6.67.237) State REPORTING going to sleep
2016-06-02 06:32:42.216503 [DEBUG] switch_core_state_machine.c:569 (sofia/external/65079...@107.6.67.237) State Change CS_REPORTING -> CS_DESTROY
2016-06-02 06:32:42.216503 [DEBUG] switch_core_session.c:1646 Session 5 (sofia/external/65079...@107.6.67.237) Locked, Waiting on external entities
2016-06-02 06:32:42.216503 [NOTICE] switch_core_session.c:1664 Session 5 (sofia/external/65079...@107.6.67.237) Ended
2016-06-02 06:32:42.216503 [NOTICE] switch_core_session.c:1668 Close Channel sofia/external/65079...@107.6.67.237 [CS_DESTROY]
2016-06-02 06:32:42.216503 [DEBUG] switch_core_state_machine.c:700 (sofia/external/65079...@107.6.67.237) Running State Change CS_DESTROY
2016-06-02 06:32:42.216503 [DEBUG] switch_core_state_machine.c:710 (sofia/external/65079...@107.6.67.237) State DESTROY
2016-06-02 06:32:42.216503 [DEBUG] mod_sofia.c:342 sofia/external/65079...@107.6.67.237 SOFIA DESTROY
2016-06-02 06:32:42.216503 [DEBUG] switch_core_state_machine.c:181 sofia/external/65079...@107.6.67.237 Standard DESTROY
2016-06-02 06:32:42.216503 [DEBUG] switch_core_state_machine.c:710 (sofia/external/65079...@107.6.67.237) State DESTROY going to sleep
2016-06-02 06:32:42.656534 [DEBUG] switch_scheduler.c:144 Deleting task 3 switch_ivr_schedule_hangup (b81b12a3-cb37-4e7f-93ea-56dc86393638)

Maybe I should put my account number in the calling card field and see what happens :)
Thanks,

Steve

On 5/31/2016 2:27 PM, Samir Doshi wrote:

Mister Woose

unread,
Jun 2, 2016, 7:03:22 AM6/2/16
to as...@googlegroups.com
Hi Samir,

Here is a siptrace which shows that the DID never appears in the header ... when I call an asterisk box with the same provider I get a "To":  Is FS stripping the header?

INVITE sip:67866...@76.105.83.149 SIP/2.0
Via: SIP/2.0/UDP 75.127.65.130:5060;branch=z9hG4bK7b8857ee;rport
Max-Forwards: 70
From: "+16507972346" <sip:65079...@75.127.65.130>;tag=as0c276bb8
To: <sip:67866...@76.105.83.149>
Contact: <sip:65079...@75.127.65.130:5060>
Call-ID: 18970b702cbdd4d7...@75.127.65.130:5060
CSeq: 102 INVITE
User-Agent: voip.ms
Date: Thu, 02 Jun 2016 11:00:46 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Remote-Party-ID: "+16507972346" <sip:65079...@75.127.65.130>;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 270



On 5/31/2016 2:27 PM, Samir Doshi wrote:
siptrace-incoming call.txt

Samir Doshi

unread,
Jun 2, 2016, 1:44:23 PM6/2/16
to ASTPP
Nope FS is not doing any manipulation with the headers. 

If you are not seeing your DID number in sip logs then your provider might not sending it to FS and due to that its appearing. Please check routing configuration at provider end. 



Best Regards
--
Samir Doshi
iNextrix Technologies Pvt. Ltd.
http://www.inextrix.com



Disclaimer:
The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.

Reply all
Reply to author
Forward
Message has been deleted
0 new messages