Hi Alan, We recently changed (in 'Elite') the bgcf.json file to make it require SIP URIs - this change was done to allow users to configure what transport should be used when routing to a trunk.
Can you attach the logs from the Sprout/Bono on your other deployment - I agree that the route and request URIs look wrong, but I can't see currently why they've switched. Can you also show your bgcf configuration? Ellie -----Original Message----- From: Kwon, Alan [mailto:[email protected]] Sent: 09 May 2014 18:32 To: Eleanor Merry; [email protected] Subject: Re: [Clearwater] Tel URI Hi Ellie, Thanks for the response. I saw one of the old mail archive answers and it had an IP address, but anyways, I changed to sip URI and it's getting there... However, once the request reaches example.com's IBCF, it's not routing the request properly. I think it's because the Request URI and the Route-header are reversed. This is the log from Bono/IBCF on example.com side: 09-05-2014 17:10:48.506 Debug pjsip: sip_endpoint.c Processing incoming message: Request msg OPTIONS/cseq=29760 (rdata0x7feff40415c8) 09-05-2014 17:10:48.506 Verbose stack.cpp:226: RX 2216 bytes Request msg OPTIONS/cseq=29760 (rdata0x7feff40415c8) from TCP 10.12.92.97:43674: --start msg-- OPTIONS sip:10.12.92.27:5058 SIP/2.0 Record-Route: <sip:sprout.cwims.iot1.com:5054;transport=TCP;lr> Record-Route: <sip:10.12.92.96:5058;transport=TCP;lr> Record-Route: <sip:[email protected]:5060;transport=TCP;lr> Via: SIP/2.0/TCP 10.12.92.97:43674;rport;branch=z9hG4bKPj8oFjRgzBduQKFJ6PRbmECK.bsSKS8H7o Via: SIP/2.0/TCP 10.12.92.96:58322;rport=58322;received=10.12.92.96;branch=z9hG4bKPjE5Jwx72D QPubCo9VL.eLZuZ37TbDfkRB Via: SIP/2.0/TCP 172.25.50.89:58844;rport=58844;received=172.25.50.89;branch=z9hG4bKPjtwdDnx nUJ2iBQ4Sz-NPi5tQg.IHa1KUm Max-Forwards: 68 From: <sip:[email protected]>;tag=jSUz62-NXHH2p1vJEsTiN3sOZpJyhmw0 To: <sip:[email protected];user=phone> Call-ID: OqAg1gqMorR.at3-NFsmV5NnlVoSqX6M CSeq: 29760 OPTIONS User-Agent: IM-client/OMA1.0 RCSAndrd/2.4.7 COMLib/3.3.8 Contact: <sip:[email protected]:58844;transport=TCP;ob>;+g.3gpp.iari-ref="ur n%3Aurn-7%3A3gpp-application.ims.iari.joyn.intmsg,urn%3Aurn-7%3A3gpp-applic ation.i ms.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftstandfw,ur n%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb,urn%3Aurn-7%3A3gpp-applic ation.ims.iari.r cs.geopush,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft,urn%3Aurn-7%3A3g pp-application.ims.iari.rcse.im,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs e.stickers";+g.3 gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.gsma.rcs.ipcall ;+g.gsma.rcs.ipvideocallonly;video;+sip.instance="<urn:gsma:imei:35526604-1 20549-1>" Accept-Contact: *;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.joyn.intmsg,urn %3Aurn-7%3A3gpp-application.ims.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-applicat ion.ims.iari.rcs.ftstandfw,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftth umb,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopush,urn%3Aurn-7%3A3gpp- application.ims. iari.rcse.ft,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im,urn%3Aurn-7%3A 3gpp-application.ims.iari.rcse.stickers";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3g pp-service.ims.i csi.mmtel";+g.gsma.rcs.ipcall;+g.gsma.rcs.ipvideocallonly;video Accept: application/sdp P-Asserted-Identity: <sip:[email protected]> Session-Expires: 600 Route: <sip:[email protected]> Content-Length: 0 --end msg-- 09-05-2014 17:10:48.506 Debug statistic.cpp:103: Send new value for statistic incoming_requests, size 1 09-05-2014 17:10:48.506 Debug zmq_lvc.cpp:167: Update to incoming_requests statistic 09-05-2014 17:10:48.506 Debug zmq_lvc.cpp:250: Clearing message cache for 0x7ff00402a170 09-05-2014 17:10:48.507 Debug stack.cpp:411: Queuing cloned received message 0x7feff4047398 for worker threads 09-05-2014 17:10:48.507 Debug statistic.cpp:103: Send new value for statistic queue_size, size 5 09-05-2014 17:10:48.507 Debug zmq_lvc.cpp:167: Update to queue_size statistic 09-05-2014 17:10:48.507 Debug zmq_lvc.cpp:250: Clearing message cache for 0x7ff0040334b0 09-05-2014 17:10:48.507 Debug stack.cpp:189: Worker thread dequeue message 0x7feff4047398 09-05-2014 17:10:48.507 Debug pjsip: sip_endpoint.c Distributing rdata to modules: Request msg OPTIONS/cseq=29760 (rdata0x7feff4047398) 09-05-2014 17:10:48.507 Debug pjsip: endpoint Response msg 200/OPTIONS/cseq=29760 (tdta0x7fefe4002ba0) created 09-05-2014 17:10:48.507 Verbose stack.cpp:242: TX 827 bytes Response msg 200/OPTIONS/cseq=29760 (tdta0x7fefe4002ba0) to TCP 10.12.92.97:43674: --start msg-- SIP/2.0 200 OK Via: SIP/2.0/TCP 10.12.92.97:43674;rport=43674;received=10.12.92.97;branch=z9hG4bKPj8oFjRgzB duQKFJ6PRbmECK.bsSKS8H7o Via: SIP/2.0/TCP 10.12.92.96:58322;rport=58322;received=10.12.92.96;branch=z9hG4bKPjE5Jwx72D QPubCo9VL.eLZuZ37TbDfkRB Via: SIP/2.0/TCP 172.25.50.89:58844;rport=58844;received=172.25.50.89;branch=z9hG4bKPjtwdDnx nUJ2iBQ4Sz-NPi5tQg.IHa1KUm Record-Route: <sip:sprout.cwims.iot1.com:5054;transport=TCP;lr> Record-Route: <sip:10.12.92.96:5058;transport=TCP;lr> Record-Route: <sip:[email protected]:5060;transport=TCP;lr> Call-ID: OqAg1gqMorR.at3-NFsmV5NnlVoSqX6M From: <sip:[email protected]>;tag=jSUz62-NXHH2p1vJEsTiN3sOZpJyhmw0 To: <sip:[email protected];user=phone>;tag=z9hG4bKPj8oFjRgzBduQKFJ6PR bmECK.bsSKS8H7o CSeq: 29760 OPTIONS Content-Length: 0 --end msg-- 09-05-2014 17:10:48.507 Debug pjsip: tdta0x7fefe400 Destroying txdata Response msg 200/OPTIONS/cseq=29760 (tdta0x7fefe4002ba0) I expected the request to look like: OPTIONS sip:[email protected] SIP/2.0 Route: <sip:10.12.92.27:5058> I'm not sure why Bono/IBCF is responding with 200 OK either... Thanks, Alan On 5/9/14 11:46 AM, "Eleanor Merry" <[email protected]> wrote: >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-Sp >>>>e 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
