Hi Alan, You do need to specify "trusted_peers" in user_settings to enable IBCF functionality on a Bono node.
If there isn't a route specified for a domain in the bgcf.json file, Sprout will attempt to route directly to the domain. You need to define BGCF routing if Sprout can't directly route to the domain (e.g. if the domain isn't resolvable, the domain to route to doesn't trust Sprout, ...). As you suggest, there would typically be agreements in place that control what traffic is allowed between operators. The IBCF nodes are part of a single deployment though - they accept traffic from and route traffic to other deployments according to their particular configuration. In your case below, the routes in the bgcf.json file need to be valid SIP URIs. Sprout has failed to parse the route 10.12.92.27 as a SIP URI, so it fell back to routing directly to example.com, which it couldn't resolve. Can you change the route to a valid SIP URI, reload Sprout and retry? Ellie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kwon, Alan Sent: 08 May 2014 22:12 To: [email protected] Subject: Re: [Clearwater] Tel URI Hi Ellie, I got few more questions regarding multi-domain setup. My domain is "cwims.iot1.com". I have a All-In-One deployment using "example.com", but I should be able to route my messages to any domain. I'm just using "example.com" to represent an external domain. First, do I have to specify "trusted_peers" in user_settings to enable IBCF functionality in Bono node? Also, do I have to define BGCF routing (bgcf.json) in Sprout? If so, this seems to imply that my deployment "cwims.iot1.com" will only route to domains specified in bgcf.json and likewise it'll only accept traffic from trusted_peers. Basically, subscribers in "cwims.iot1.com" can only communicate to other subscribers within the same domain or "example.com". Is this because in the real deployment, operators would only allow traffic to other operators that they would have some sort of agreement? Is IBCF host in bgcf.json expected to be some sort of a hub? For now, I went ahead and defined the following: bgcf.json { "routes" : [ { "name" : "Clearwater AIO", "domain" : "example.com", "route" : ["10.12.92.27"] } ] } And in example.com, I have user_settings: log_level=5 trusted_peers="10.12.92.96" And you can see that Bono has IBCF enabled: bono 16704 0.1 2.5 827636 42216 ? Sl 20:35 0:02 /usr/share/clearwater/bin/bono --domain example.com --localhost 10.12.92.27,10.12.92.27 --alias 10.12.92.27 --pcscf 5060,5058 --webrtc-port 5062 --routing-proxy 10.12.92.27,5052,50,600 --sas 0.0.0.0,[email protected] --pjsip-threads 1 --worker-threads 1 -a /var/log/bono -F /var/log/bono -L 5 --ibcf 10.12.92.96 But, the routing is still failing. Below is the log from Sprout node (cwims.iot1.com). As you can see, ENUM translation successfully replaced request URI to sip:[email protected]. Then bgcfservice.cpp does a lookup and found route to domain example.com. But, instead of just using 10.12.92.27 from the gbcf routing table, it does a DNS lookup on example.com and eventually it leads to failure. Is this a bug or am I missing something? 08-05-2014 19:47:39.922 Debug stateful_proxy.cpp:2246: Translating URI 08-05-2014 19:47:39.923 Debug dnsresolver.cpp:141: Sending DNS NAPTR query for 1.0.0.4.4.4.4.5.5.5.1.iot1.com 08-05-2014 19:47:39.923 Debug enumservice.cpp:435: Got NAPTR record: 100 10 "E2U+SIP" "U" "!^.*$!sip:[email protected]!" 08-05-2014 19:47:39.923 Debug enumservice.cpp:70: Split regex into match=^.*$, replace=sip:[email protected] 08-05-2014 19:47:39.923 Debug enumservice.cpp:375: Enum lookup completes: sip:[email protected] 08-05-2014 19:47:39.923 Debug stateful_proxy.cpp:1808: Update request URI to sip:[email protected] 08-05-2014 19:47:39.923 Info stateful_proxy.cpp:1594: Route request to domain example.com 08-05-2014 19:47:39.923 Debug bgcfservice.cpp:132: Getting route for URI domain example.com via BGCF lookup 08-05-2014 19:47:39.923 Info bgcfservice.cpp:138: Found route to domain example.com 08-05-2014 19:47:39.923 Debug acr.cpp:48: Created ACR (0x7f3538044d20) 08-05-2014 19:47:39.923 Debug stateful_proxy.cpp:3363: Allocating transaction and data for target 0 08-05-2014 19:47:39.923 Debug pjsip: tsx0x7f353806a Transaction created for Request msg OPTIONS/cseq=18776 (tdta0x7f3538067420) 08-05-2014 19:47:39.923 Debug stateful_proxy.cpp:3383: Adding trail identifier 103 to UAC transaction 08-05-2014 19:47:39.923 Debug stateful_proxy.cpp:3402: Updating request URI and route for target 0 08-05-2014 19:47:39.923 Debug stateful_proxy.cpp:3834: Resolve next hop destination 08-05-2014 19:47:39.923 Debug pjutils.cpp:489: Next hop node is encoded in Request-URI 08-05-2014 19:47:39.923 Debug sipresolver.cpp:85: SIPResolver::resolve for name example.com, port 0, transport -1, family 2 08-05-2014 19:47:39.923 Debug baseresolver.cpp:480: Attempt to parse example.com as IP address 08-05-2014 19:47:39.923 Debug sipresolver.cpp:144: Do NAPTR look-up for example.com 08-05-2014 19:47:39.923 Debug ttlcache.h:171: Found the entry in the cache 08-05-2014 19:47:39.923 Debug sipresolver.cpp:158: NAPTR resolved to transport 17 08-05-2014 19:47:39.923 Debug sipresolver.cpp:295: Perform A/AAAA record lookup only, name = _sip._udp.example.com 08-05-2014 19:47:39.923 Debug dnscachedresolver.cpp:136: Create cache entry pending query 08-05-2014 19:47:39.924 Debug dnscachedresolver.cpp:148: Create and execute DNS query transaction 08-05-2014 19:47:39.924 Debug dnscachedresolver.cpp:154: Wait for query responses 08-05-2014 19:47:39.924 Debug dnscachedresolver.cpp:384: Received DNS response for _sip._udp.example.com type A 08-05-2014 19:47:39.924 Debug dnscachedresolver.cpp:534: Adding _sip._udp.example.com to cache expiry list with expiry time of 0 08-05-2014 19:47:39.924 Debug dnscachedresolver.cpp:158: Received all query responses 08-05-2014 19:47:39.924 Debug dnscachedresolver.cpp:179: Pulling 0 records from cache for _sip._udp.example.com A 08-05-2014 19:47:39.924 Debug baseresolver.cpp:359: Found 0 A/AAAA records, randomizing 08-05-2014 19:47:39.924 Debug baseresolver.cpp:418: Adding 0 servers from blacklist 08-05-2014 19:47:39.924 Info pjutils.cpp:760: Resolved destination URI sip:[email protected] to 0 servers 08-05-2014 19:47:39.924 Debug stateful_proxy.cpp:3883: Failed to send request (70006 Not found (PJ_ENOTFOUND)) 08-05-2014 19:47:39.924 Debug stateful_proxy.cpp:3025: tsx0x7f353806a438 - Not forked request 08-05-2014 19:47:39.924 Debug pjsip: tsx0x7f3538004 Sending Response msg 408/OPTIONS/cseq=18776 (tdta0x7f3538005700) in state Trying Thank you, Alan On 5/7/14 4:02 PM, "Kwon, Alan" <[email protected]> wrote: >Hi Ellie, > >Thank you for the response. I'm using ENUM rules on BIND and I don't >have it fully working yet, but it's resolving to the correct domain now. > >OPTIONS sip:[email protected];user=phone SIP/2.0 >From: ><sip:[email protected]>;tag=gKgrZ1oLEpAy6AvtbdjYr.-dPR4PFRStTo: ><sip:[email protected];user=phone> > >07-05-2014 19:54:45.636 Debug stateful_proxy.cpp:2246: Translating URI >07-05-2014 19:54:45.636 Debug dnsresolver.cpp:141: Sending DNS NAPTR >query for 1.0.0.4.4.4.4.5.5.5.1.iot1.com >07-05-2014 19:54:45.637 Debug enumservice.cpp:435: Got NAPTR record: >100 >10 "E2U+SIP" "U" "!^.*$!sip:[email protected]!" >07-05-2014 19:54:45.637 Debug enumservice.cpp:70: Split regex into >match=^.*$, replace=sip:[email protected] >07-05-2014 19:54:45.637 Debug enumservice.cpp:375: Enum lookup completes: >sip:[email protected] >07-05-2014 19:54:45.637 Debug stateful_proxy.cpp:1808: Update request >URI to sip:[email protected] >07-05-2014 19:54:45.637 Info stateful_proxy.cpp:1594: Route request to >domain example.com > > >Thank you, >Alan > > > > >On 5/7/14 11:30 AM, "Eleanor Merry" <[email protected]> wrote: > >>Hi Alan, >> >>You can use ENUM and SIP URIs in your case below. >> >>You will need an ENUM rule that rewrites the domain of numbers that >>belong to DomainB, e.g. a jsonized version would be: >>{ >> "number_blocks" : [ >> { >> "name" : "Numbers in DomainB", >> "prefix" : "15554444", >> "regex" : "!(^.*$)!sip:\\1@DomainB!" >> } >>} >> >>Sprout receives an INVITE to "sip:+15554444001@DomainA". It pulls out >>'+15554444001' from the SIP URI, does an ENUM lookup on the number to >>see if the domain should be rewritten, finds the ENUM rule and >>rewrites DomainA to DomainB. >> >>Ellie >> >> >> >>-----Original Message----- >>From: Kwon, Alan [mailto:[email protected]] >>Sent: 07 May 2014 16:58 >>To: Eleanor Merry; [email protected] >>Subject: Re: Tel URI >> >>Hi Ellie, >> >>The use case that I'm trying to test is a multi-domain use case. Let's >>say user A (1-555-444-3001) belongs to DomainA and B (1-555-444-4001) >>belongs to Domain B. When user A tries to reach out to user B, in the >>Contacts, A only has B's telephone number. If I configure the devices >>to use SIP URI, INVITE will be sent to "sip:+15554444001@DomainA" and >>since B belongs to DomainB, it obviously won't reach B. >> >>That's the reason I'm configuring the devices to use Tel-URI. So that >>Tel:+15554444001 would be translated by ENUM to sip:+15554444001@DomainB. >>So, is this type of multi-domain use case not currently supported by >>Clearwater? >> >>Thanks, >>Alan >> >> >> >>On 5/7/14 10:42 AM, "Eleanor Merry" <[email protected]> wrote: >> >>>Hi Alan, >>> >>>We don't currently support Tel-URIs. >>> >>>While Clearwater does have function to support ENUM lookups for a TEL >>>URI (INVITEs only), this function isn't tested as part of our QA (and >>>so there may be issues with it). We're expecting to add support for >>>TEL URIs in the future - in the meantime are you able to use SIP URIs? >>> >>>Clearwater also supports ENUM lookups for numbers embedded in a SIP URI. >>> >>>Ellie >>> >>>-----Original Message----- >>>From: [email protected] >>>[mailto:[email protected]] On Behalf Of >>>Kwon, Alan >>>Sent: 06 May 2014 23:13 >>>To: [email protected] >>>Subject: [Clearwater] Tel URI >>> >>>Hi, >>> >>>I know that in the WIKI >>>(https://github.com/Metaswitch/clearwater-docs/wiki/SIP-Interface-Spe >>>ci fic ations), it says Tel-URI is not supported, but I was under the >>>impression that you simply can't use the Tel-URI as your public URI, >>>but would be able to send a request out to a Tel-URI since there's a >>>support for ENUM server. >>> >>>I tried it today and I'm receiving 416. >>> >>>OPTIONS tel:+15554443001 SIP/2.0 >>>From: >>><sip:[email protected]>;tag=sYys9XoDHolpvwEf7Jv2o9dQdDSP-Nbo >>>To: <tel:+15554443001> >>> >>>SIP/2.0 416 Unsupported URI Scheme >>>From: >>><sip:[email protected]>;tag=sYys9XoDHolpvwEf7Jv2o9dQdDSP-Nbo >>>To: <tel:+15554443001>;tag=z9hG4bKPjJqZHB7Oo3n7ITZ9BbVvlEpO5czHUA0y6 >>> >>>So, Tel-URI is not supported at all? Then, what's the ENUM server >>>used for? >>> >>>Thanks, >>>Alan >>> >>>_______________________________________________ >>>Clearwater mailing list >>>[email protected] >>>http://lists.projectclearwater.org/listinfo/clearwater >> > >_______________________________________________ >Clearwater mailing list >[email protected] >http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
