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-Speci
>>>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
