Hi Ellie, I don’t see ‘orig’ parameter in the Route header in the AS that’s part of the cwims.iot1.com deployment. I see ‘orig’ in the P-Served-User. Is the ‘orig’ supposed to be in the Route header instead?
INVITE sip:[email protected];user=phone SIP/2.0 From: <sip:[email protected]>;tag=v6QaHqyN5kICXLdmhYChiBGzqVm8.iut To: <sip:[email protected];user=phone> P-Asserted-Identity: <sip:[email protected]> P-Served-User: <sip:[email protected]>;sescase=orig;regstate=reg Route: <sip:10.12.92.71:5510;lr> Route: <sip:[email protected]:5054;lr> Thanks, Alan On 5/21/14, 12:32 PM, "Eleanor Merry" <[email protected]> wrote: >Hi Alan, > >The application server that's part of the cwims.iot1.com deployment is >part of the originating processing, and so should add the 'orig' >parameter on the INVITE it sends (the request it receives would have had >the 'orig' parameter in the route headers). >The application server that's part of the example.com deployment is part >of the terminating processing, and so should not add the 'orig' parameter >on the INVITE it sends (the request it receives won't have the 'orig' >parameter either). > >Can you change your setup so that the application servers will add the >'orig' parameter only if the request they receive also has the 'orig' >parameter? > >Ellie > >-----Original Message----- >From: Kwon, Alan [mailto:[email protected]] >Sent: 19 May 2014 18:26 >To: Eleanor Merry; [email protected] >Subject: Re: [Clearwater] Tel URI > >Hi Ellie, > > >Thanks for the clarification. I see other section (5.7.3) also mentioning >AS should place "orig" in the top most Route-header. > >I have the iFCs setup so that INVITE's are sent to my AS, whether >originating from a user or it's coming in from other domain (I-CSCF/IBCF). >When the INVITE gets across to the example.com domain, it's to my AS and >as suggested, I'm generating a new INVITE with the "orig" in the Route >header: > >(Only showing the relevant headers) >INVITE sip:[email protected] SIP/2.0 >Via: SIP/2.0/UDP >10.12.92.73:5510;branch=z9hG4bK810474fb-2a82-4482-952b-c26f8054fc7f >From: <sip:[email protected]>;tag=94d6c588-0f1a-4380-b73e-daf0c73c6042 >To: <sip:[email protected];user=phone> >P-Asserted-Identity: <sip:[email protected]> > >Route: <sip:10.12.92.27:5054;transport=UDP;lr;orig> > >This causes a problem at Sprout node when it tries to look up AS chain >for the originator. It's looking for Subscriber Data for the originator >(P-Asserted-Identity) which belongs to another domain. It realizes that >URI is not locally hosted, yet it proceeds to look up iFC and eventually >returns 404. When it knows that URI is not locally hosted, shouldn't it >just treat as iFC mismatch and just route to the terminating user? > > >19-05-2014 15:42:14.869 Debug pjsip: tsx0x1e14888 State changed from >Trying to Proceeding, event=TX_MSG >19-05-2014 15:42:14.869 Debug stateful_proxy.cpp:361: tsx0x1e14888 - >tu_on_tsx_state UAS, TSX_STATE TX_MSG state=Proceeding >19-05-2014 15:42:14.869 Debug stateful_proxy.cpp:2486: Looking for AS >chain for incoming transaction request, serving state = orig (new) >19-05-2014 15:42:14.869 Debug pjutils.cpp:363: Served user from >P-Asserted-Identity header >19-05-2014 15:42:14.869 Debug ifchandler.cpp:854: URI is not locally >hosted >19-05-2014 15:42:14.869 Debug stateful_proxy.cpp:2542: Looking up iFCs >for for new AS chain >19-05-2014 15:42:14.869 Debug hssconnection.cpp:397: Making Homestead >request for /impu//reg-data >19-05-2014 15:42:14.869 Debug httpconnection.cpp:456: Sending HTTP request >: http://10.12.92.27:8888/impu//reg-data (try 0) on new connection >19-05-2014 15:42:14.999 Debug httpconnection.cpp:482: Received HTTP error >response : http://10.12.92.27:8888/impu//reg-data : HTTP response code >said error >19-05-2014 15:42:14.999 Error httpconnection.cpp:536: >http://10.12.92.27:8888/impu//reg-data failed at server 10.12.92.27 : >HTTP response code said error (22 502) : fatal >19-05-2014 15:42:14.999 Error httpconnection.cpp:574: cURL failure with >cURL error code 22 (see man 3 libcurl-errors) and HTTP error code 502 >19-05-2014 15:42:14.999 Error hssconnection.cpp:420: Could not get >subscriber data from HSS >19-05-2014 15:42:14.999 Debug stateful_proxy.cpp:2559: Single Record-Route >- initiation of originating handling >19-05-2014 15:42:14.999 Info stateful_proxy.cpp:2206: Reject request with >404 due to failed iFC lookup >19-05-2014 15:42:14.999 Debug pjsip: tsx0x1e14888 Sending Response msg >408/INVITE/cseq=1 (tdta0x1dc0cd0) in state Proceeding >19-05-2014 15:42:14.999 Debug pjsip: tdta0x1ce57d0 Destroying txdata >Response msg 100/INVITE/cseq=1 (tdta0x1ce57d0) >19-05-2014 15:42:14.999 Verbose stack.cpp:242: TX 386 bytes Response msg >408/INVITE/cseq=1 (tdta0x1dc0cd0) to UDP 10.12.92.73:5510: >--start msg-- > >SIP/2.0 404 Not Found >Via: SIP/2.0/UDP >10.12.92.73:5510;received=10.12.92.73;branch=z9hG4bK810474fb-2a82-4482-952 >b >-c26f8054fc7f >Call-ID: d62c9720-5924-4022-9cff-5a28ead45968 >From: <sip:[email protected]>;tag=94d6c588-0f1a-4380-b73e-daf0c73c6042 >To: ><sip:[email protected];user=phone>;tag=z9hG4bK810474fb-2a82-4482 >- >952b-c26f8054fc7f >CSeq: 1 INVITE >Content-Length: 0 > >Thank you, >Alan > > > >On 5/16/14, 12:31 PM, "Eleanor Merry" <[email protected]> >wrote: > >>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.bsSKS8 >>>>H >>>>7 >>>>o >>>>Via: SIP/2.0/TCP >>>>10.12.92.96:58322;rport=58322;received=10.12.92.96;branch=z9hG4bKPjE5 >>>>J >>>>w >>>>x72 >>>>D >>>>QPubCo9VL.eLZuZ37TbDfkRB >>>>Via: SIP/2.0/TCP >>>>172.25.50.89:58844;rport=58844;received=172.25.50.89;branch=z9hG4bKPj >>>>t >>>>w >>>>dDn >>>>x >>>>nUJ2iBQ4Sz-NPi5tQg.IHa1KUm >>>>Max-Forwards: 68 >>>>From: >>>><sip:[email protected]>;tag=jSUz62-NXHH2p1vJEsTiN3sOZpJyhmw >>>>0 >>>>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-r >>>>e >>>>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.ftstan >>>>d >>>>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.ia >>>>r >>>>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:3552 >>>>6 >>>>6 >>>>04- >>>>1 >>>>20549-1>" >>>>Accept-Contact: >>>>*;+g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.joyn.intm >>>>s >>>>g >>>>,ur >>>>n >>>>%3Aurn-7%3A3gpp-application.ims.iari.rcs.fthttp,urn%3Aurn-7%3A3gpp-ap >>>>p >>>>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%3 >>>>A >>>>3 >>>>gpp >>>>- >>>>application.ims. >>>>iari.rcse.ft,urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im,urn%3Aur >>>>n >>>>- >>>>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=z9hG4bKPj8o >>>>F >>>>j >>>>Rgz >>>>B >>>>duQKFJ6PRbmECK.bsSKS8H7o >>>>Via: SIP/2.0/TCP >>>>10.12.92.96:58322;rport=58322;received=10.12.92.96;branch=z9hG4bKPjE5 >>>>J >>>>w >>>>x72 >>>>D >>>>QPubCo9VL.eLZuZ37TbDfkRB >>>>Via: SIP/2.0/TCP >>>>172.25.50.89:58844;rport=58844;received=172.25.50.89;branch=z9hG4bKPj >>>>t >>>>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-NXHH2p1vJEsTiN3sOZpJyhmw >>>>0 >>>>To: >>>><sip:[email protected];user=phone>;tag=z9hG4bKPj8oFjRgzBduQ >>>>K >>>>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.-dPR4PF >>>>>>R >>>>>>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-N >>>>>>>>b >>>>>>>>o >>>>>>>>To: <tel:+15554443001> >>>>>>>> >>>>>>>>SIP/2.0 416 Unsupported URI Scheme >>>>>>>>From: >>>>>>>><sip:[email protected]>;tag=sYys9XoDHolpvwEf7Jv2o9dQdDSP-N >>>>>>>>b >>>>>>>>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
