Hi Alan, The orig parameter is necessary (see TS 24.229, s5.4.3.1). It's how the I/S-CSCF knows to apply originating services to the request (as there's no ODI token on the route header either).
Ellie -----Original Message----- From: Kwon, Alan [mailto:[email protected]] Sent: 14 May 2014 18:36 To: Eleanor Merry; [email protected] Subject: Re: [Clearwater] Tel URI Hi Ellie, Adding ;lr to the SIP URI fixed the problem. SIP OPTIONS is making it across to the other side. Unlike the OPTIONS, the INVITE is routed to my AS through iFC match. The INVITE that comes from my AS to the Sprout gets treated as "terminating" case and it does not do a ENUM lookup. I managed to fix the issue by adding this header to the INVITE: Route: <sip:sprout.cwims.iot1.com:5054;transport=UDP;lr;orig> The key word seems to be ;orig. Without it, it's always treated as terminating case and end up getting 404 Not Found since 15554444001 does not exist in cwims.iot1.com domain. I saw some other cores also using this type of notation, but I'm not sure if this is per spec or just common practice. Would this be the only way for Sprout to do ENUM lookup? Thank you, Alan On 5/14/14, 10:43 AM, "Eleanor Merry" <[email protected]> wrote: >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.bsSKS8H >>7 >>o >>Via: SIP/2.0/TCP >>10.12.92.96:58322;rport=58322;received=10.12.92.96;branch=z9hG4bKPjE5J >>w >>x72 >>D >>QPubCo9VL.eLZuZ37TbDfkRB >>Via: SIP/2.0/TCP >>172.25.50.89:58844;rport=58844;received=172.25.50.89;branch=z9hG4bKPjt >>w >>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-re >>f >>="u >>r >>n%3Aurn-7%3A3gpp-application.ims.iari.joyn.intmsg,urn%3Aurn-7%3A3gpp-a >>p >>pli >>c >>ation.i >>ms.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftstand >>f >>w,u >>r >>n%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb,urn%3Aurn-7%3A3gpp-a >>p >>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.iar >>i >>.rc >>s >>e.stickers";+g.3 >>gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.gsma.rcs.i >>p >>cal >>l >>;+g.gsma.rcs.ipvideocallonly;video;+sip.instance="<urn:gsma:imei:35526 >>6 >>04- >>1 >>20549-1>" >>Accept-Contact: >>*;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.joyn.intms >>g >>,ur >>n >>%3Aurn-7%3A3gpp-application.ims.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-app >>l >>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%3A >>3 >>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=z9hG4bKPj8oF >>j >>Rgz >>B >>duQKFJ6PRbmECK.bsSKS8H7o >>Via: SIP/2.0/TCP >>10.12.92.96:58322;rport=58322;received=10.12.92.96;branch=z9hG4bKPjE5J >>w >>x72 >>D >>QPubCo9VL.eLZuZ37TbDfkRB >>Via: SIP/2.0/TCP >>172.25.50.89:58844;rport=58844;received=172.25.50.89;branch=z9hG4bKPjt >>w >>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=z9hG4bKPj8oFjRgzBduQK >>F >>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.-dPR4PFR >>>>S >>>>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-Nb >>>>>>o >>>>>>To: <tel:+15554443001> >>>>>> >>>>>>SIP/2.0 416 Unsupported URI Scheme >>>>>>From: >>>>>><sip:[email protected]>;tag=sYys9XoDHolpvwEf7Jv2o9dQdDSP-Nb >>>>>>o >>>>>>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
