I think Lelio was wondering about a pure cloud registered device, and then simply purchasing a vanity domain to overlay on top of the ugly webex one.
You know....like URL shortening <https://blog.rebrandly.com/the-history-of-url-shorteners/>. On Fri, Oct 4, 2019 at 9:57 PM NateCCIE <[email protected]> wrote: > Doesn’t cucm have the ability to look at the user portion of the URI > only? For like when you’re routing to a DN? Or I think you can add the > short domain to the list of the CUCM “owned” domains in enterprise > parameters. > > > > *From:* Ryan Huff <[email protected]> > *Sent:* Friday, October 4, 2019 8:51 PM > *To:* NateCCIE <[email protected]> > *Cc:* Lelio Fulgenzi <[email protected]>; cisco-voip voyp list < > [email protected]> > *Subject:* Re: [cisco-voip] SIP Domain substitution > > > > Hey Nate ... the original ask I think, was to do it all with DNS only and > no intervention at layer 4, which to my knowledge, DNS alone couldn’t do. > > > > Expressway search rule, CUCM LUA script... etc could all do it in reality. > > > > However, the actual goal appears to be dialing a Webex cloud registered > codec, using a non cloud uri ([email protected]), and for that Webex > Hybrid calling with Expressway B2B would get you there, and also checks the > “no additional transformation needed” box. > > > > Sent from my iPhone > > > > On Oct 4, 2019, at 22:41, NateCCIE <[email protected]> wrote: > > I am not thinking right? Can’t a dns srv get the call routed to a > specific host? Then a quick expressway transform to change the domain, and > you’re done. > > > > Think of it as a different internal domain va external domain. > > > > [email protected] does goes to expressway.companyinfrastructuredomain.com > which does a quick trans to [email protected] > > > > > > Sent from my iPhone > > > > On Oct 4, 2019, at 8:36 PM, Lelio Fulgenzi <[email protected]> wrote: > > > > > > Interesting. I’ll have to look into that. Thx. > > *-sent from mobile device-* > > > > *Lelio Fulgenzi, B.A.* | Senior Analyst > > Computing and Communications Services | University of Guelph > > Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | > N1G 2W1 > > 519-824-4120 Ext. 56354 <519-824-4120;56354> | [email protected] > > > > www.uoguelph.ca/ccs > <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631419029&sdata=Bm%2FOh%2Fp3TDYkOYis27I47D3rrDAJDEp4doaBw5lr9XA%3D&reserved=0> > | > @UofGCCS on Instagram, Twitter and Facebook > > > > [image: University of Guelph Cornerstone with Improve Life tagline] > > > On Oct 4, 2019, at 10:32 PM, Ryan Huff <[email protected]> wrote: > > Webex Hybrid Calling (with Expressway B2B), could in theory, help > accomplish this. The codec is still cloud registered, though Hybrid calling > would allow for an on-prem URI to be associated with the Webex remote > destination of the codec. > > > > The call would come into the on-prem URI via B2B like normal, and assuming > the Hybrid integration was setup correctly, ring the Webex remote > destination which rings the cloud registered codec. > > > > It’s a little bit of an ugly trombone, but it does work.. > > > > Sent from my iPhone > > > > On Oct 4, 2019, at 22:09, Lelio Fulgenzi <[email protected]> wrote: > > > > > > Darn. Double darn. > > > > Let’s hope webex offers up custom domain registration for devices soon. > > > > ‘Cause [email protected] is a bit much. > > *-sent from mobile device-* > > > > *Lelio Fulgenzi, B.A.* | Senior Analyst > > Computing and Communications Services | University of Guelph > > Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | > N1G 2W1 > > 519-824-4120 Ext. 56354 <519-824-4120;56354> | [email protected] > > > > www.uoguelph.ca/ccs > <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631419029&sdata=Bm%2FOh%2Fp3TDYkOYis27I47D3rrDAJDEp4doaBw5lr9XA%3D&reserved=0> > | > @UofGCCS on Instagram, Twitter and Facebook > > > > [image: University of Guelph Cornerstone with Improve Life tagline] > > > On Oct 4, 2019, at 9:05 PM, Ryan Huff <[email protected]> wrote: > > What it sounds like you are trying to do to me, is allow the call to > ultimately setup with a URI different than the URI that was dialed, without > the calling party being the wiser. > > > > DNS won’t be able to do anything with regards to that I don’t think, > because it really sounds like you’re trying to manipulate/transform the > called URI, and you’ll need something to interact with the SIP message > stack for that I’d think. > > > > You can create a round robin A record, that resolves to multiple IP > addresses, so when the client looks up the DNS SRV, it receives multiple > targets to try before considering the SRV target “unreachable” (SRV weights > and priorities determine the ordering of the target addresses resolved for > the client). However, this won’t have the ability to change the called URI, > which is ultimately what I think you’re attempting in the scenario (DNS and > SIP messages are on different networking layers). > > > > As Dave mentioned below, Expressway or a LUA script (sip normalization) in > CUCM seems to be uniquely qualified for what you’re wanting to do. > > Sent from my iPhone > > > > On Oct 4, 2019, at 20:40, Lelio Fulgenzi <[email protected]> wrote: > > > > > > I’ve seen some references to Cisco SIP proxy server. > > > > Would that help? > > *-sent from mobile device-* > > > > *Lelio Fulgenzi, B.A.* | Senior Analyst > > Computing and Communications Services | University of Guelph > > Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | > N1G 2W1 > > 519-824-4120 Ext. 56354 <519-824-4120;56354> | [email protected] > > > > www.uoguelph.ca/ccs > <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631429128&sdata=FY1WR%2FxfTNm4GprcfWb7uiZ4SxVyg6m9kMAQeTNKtbE%3D&reserved=0> > | > @UofGCCS on Instagram, Twitter and Facebook > > > > [image: University of Guelph Cornerstone with Improve Life tagline] > > > On Oct 4, 2019, at 7:46 PM, Ryan Huff <[email protected]> wrote: > > According to RFC 2782 (https://www.ietf.org/rfc/rfc2782.txt > <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc2782.txt&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631429128&sdata=OAmRMMzoz0YfzhuHqJuiHYHNI9JHtJrfTTEeesLBbDg%3D&reserved=0>), > it does not, under the “Target Definition”; “there must be one or more > address records for this name, the name must not be an alias”. > > > > However, I can tell you that I have used a CNAME in the SRV target field > before, and it appeared to work at the time. Still, depending on the > application, doing so could potentially cause some weird issue with regards > to PTR or something. > > > > Sent from my iPhone > > > > On Oct 4, 2019, at 19:10, Brian Meade <[email protected]> wrote: > > > > I don't think DNS SRV records support CNAME. Even then, it would only > change where it was sent to and not the SIP headers. > > > > On Fri, Oct 4, 2019 at 12:26 PM Lelio Fulgenzi <[email protected]> wrote: > > Yeah – I’d want this to happen all within DNS. But of course, in a > supported fashion. I’m not interested in spending time modifying > infrastructure at this time. > > > > I’ve done some searching, and there’s talk of RR records, but we haven’t > found much documentation. > > > > > > --- > > *Lelio Fulgenzi, B.A.* | Senior Analyst > > Computing and Communications Services | University of Guelph > > Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | > N1G 2W1 > > 519-824-4120 Ext. 56354 | [email protected] > > > > www.uoguelph.ca/ccs > <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631439039&sdata=xk83CvE%2F9bV5TVtdcEAJ7jN5lrRb%2FU%2FHITHUgMV%2FpOQ%3D&reserved=0> > | @UofGCCS on Instagram, Twitter and Facebook > > > > <image001.png> > > > > *From:* Dave Goodwin <[email protected]> > *Sent:* Friday, October 4, 2019 12:09 PM > *To:* Lelio Fulgenzi <[email protected]> > *Cc:* cisco-voip voyp list <[email protected]> > *Subject:* Re: [cisco-voip] SIP Domain substitution > > > > Are you wanting this to all happen within DNS instead of happening within > a SIP UA? As far as I understand, if DNS redirected somewhere (SRV or CNAME > record for example) it would not change the destination URI the originator > is trying to reach. The SIP protocol has redirection codes (such as 301 or > 302) but whether or how you might be able to use them depends on the SIP > UAs being used. > > > > You might also be able to use something like a SIP normalization script > (CUCM), SIP profiles (CUBE), or maybe search pattern replacements > (Expressway) to just translate the domain as calls flow in/out. I'm > guessing what might be feasible without knowing more of the picture. > > > > On Fri, Oct 4, 2019 at 11:10 AM Lelio Fulgenzi <[email protected]> wrote: > > > > Does SIP allow for domain name substitution? > > > > By this I mean, instead of advertising or dialing > [email protected] I want to use [email protected] > > > > But I don’t want to have to reorganize and reprogram anything. > > > > I just want the DNS to say, “hey, use this domain instead and try again.” > > *-sent from mobile device-* > > > > *Lelio Fulgenzi, B.A.* | Senior Analyst > > Computing and Communications Services | University of Guelph > > Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | > N1G 2W1 > > 519-824-4120 Ext. 56354 <519-824-4120;56354> | [email protected] > > > > www.uoguelph.ca/ccs > <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631439039&sdata=xk83CvE%2F9bV5TVtdcEAJ7jN5lrRb%2FU%2FHITHUgMV%2FpOQ%3D&reserved=0> > | > @UofGCCS on Instagram, Twitter and Facebook > > > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631449048&sdata=C8NC3MxyaL9c81vM%2FieyvT%2FJsIXqCXKrQtXN22FV5Js%3D&reserved=0> > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631459057&sdata=kMZSGgC0agkvMhIfsv9mMvJEmSKfbh5FcfW7KoUXQmY%3D&reserved=0> > > _______________________________________________ > cisco-voip mailing list > [email protected] > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C8490bfb695e94274db6d08d7491ffa5a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058274001837045&sdata=zfbMgSZMo1JkN8aVUEQ0s%2B18Hgsoa9887UvQ3z1v6rw%3D&reserved=0 > <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C9b720a4af69b41bebb5008d7493d7691%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637058400631459057&sdata=kMZSGgC0agkvMhIfsv9mMvJEmSKfbh5FcfW7KoUXQmY%3D&reserved=0> > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
