Hi Alan, The SIP URI you have doesn't mandate loose routing - so when the Sprout in cwims.iot1.com routes the request it rewrites the Req URI with sip:10.12.92.27:5058. I can't currently see why the a route header containing sip:[email protected] is being added though.
Can you add ;lr to your SIP URI in the bgcf.json file and reload sprout (service sprout reload)? Ellie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kwon, Alan Sent: 14 May 2014 16:03 To: [email protected] Subject: Re: [Clearwater] Tel URI Hi Ellie, Thanks for looking into this issue. Attached is the relevant extraction of the log file from both Bono and Sprout nodes. They are labeled as ³Bono log² and ³Sprout log². My bgcf.json definition under Sprout node is as follows: { "routes" : [ { "name" : "Clearwater AIO", "domain" : "example.com", "route" : ["sip:10.12.92.27:5058"] } ] } Thank you, Alan On 5/14/14, 7:35 AM, "Eleanor Merry" <[email protected]> wrote: >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.bsSKS8H7 >o >Via: SIP/2.0/TCP >10.12.92.96:58322;rport=58322;received=10.12.92.96;branch=z9hG4bKPjE5Jw >x72 >D >QPubCo9VL.eLZuZ37TbDfkRB >Via: SIP/2.0/TCP >172.25.50.89:58844;rport=58844;received=172.25.50.89;branch=z9hG4bKPjtw >dDn >x >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 >="u >r >n%3Aurn-7%3A3gpp-application.ims.iari.joyn.intmsg,urn%3Aurn-7%3A3gpp-ap >pli >c >ation.i >ms.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftstandf >w,u >r >n%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb,urn%3Aurn-7%3A3gpp-ap >pli >c >ation.ims.iari.r >cs.geopush,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft,urn%3Aurn-7% >3A3 >g >pp-application.ims.iari.rcse.im,urn%3Aurn-7%3A3gpp-application.ims.iari >.rc >s >e.stickers";+g.3 >gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.gsma.rcs.ip >cal >l >;+g.gsma.rcs.ipvideocallonly;video;+sip.instance="<urn:gsma:imei:355266 >04- >1 >20549-1>" >Accept-Contact: >*;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.joyn.intmsg >,ur >n >%3Aurn-7%3A3gpp-application.ims.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-appl >ica >t >ion.ims.iari.rcs.ftstandfw,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs. >ftt >h >umb,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopush,urn%3Aurn-7%3A3 >gpp >- >application.ims. >iari.rcse.ft,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im,urn%3Aurn- >7%3 >A >3gpp-application.ims.iari.rcse.stickers";+g.3gpp.icsi-ref="urn%3Aurn-7% >3A3 >g >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=z9hG4bKPj8oFj >Rgz >B >duQKFJ6PRbmECK.bsSKS8H7o >Via: SIP/2.0/TCP >10.12.92.96:58322;rport=58322;received=10.12.92.96;branch=z9hG4bKPjE5Jw >x72 >D >QPubCo9VL.eLZuZ37TbDfkRB >Via: SIP/2.0/TCP >172.25.50.89:58844;rport=58844;received=172.25.50.89;branch=z9hG4bKPjtw >dDn >x >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=z9hG4bKPj8oFjRgzBduQKF >J6P >R >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.-dPR4PFRS >>>tTo >>>: >>><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-S >>>>>p 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
