[cisco-voip] SIP Domain substitution

Fri Oct 4 23:06:09 EDT 2019

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 <nateccie at gmail.com> 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 <ryanhuff at outlook.com>
> *Sent:* Friday, October 4, 2019 8:51 PM
> *To:* NateCCIE <nateccie at gmail.com>
> *Cc:* Lelio Fulgenzi <lelio at uoguelph.ca>; cisco-voip voyp list <
> cisco-voip at puck.nether.net>
> *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 (... at rooms.webex.com), 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 <nateccie at gmail.com> 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.
>
>
>
> Foo at company.com does goes to expressway.companyinfrastructuredomain.com
> which does a quick trans to foo at internal.local
>
>
>
>
>
> Sent from my iPhone
>
>
>
> On Oct 4, 2019, at 8:36 PM, Lelio Fulgenzi <lelio at uoguelph.ca> 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> | lelio at uoguelph.ca
>
>
>
> 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 <ryanhuff at outlook.com> 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 <lelio at uoguelph.ca> wrote:
>
> 
>
>
>
> Darn. Double darn.
>
>
>
> Let’s hope webex offers up custom domain registration for devices soon.
>
>
>
> ‘Cause room123 at acme.rooms.webex.com 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> | lelio at uoguelph.ca
>
>
>
> 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 <ryanhuff at outlook.com> 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 <lelio at uoguelph.ca> 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> | lelio at uoguelph.ca
>
>
>
> 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 <ryanhuff at outlook.com> 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 <bmeade90 at vt.edu> 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 <lelio at uoguelph.ca> 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 | lelio at uoguelph.ca
>
>
>
> 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 <dave.goodwin at december.net>
> *Sent:* Friday, October 4, 2019 12:09 PM
> *To:* Lelio Fulgenzi <lelio at uoguelph.ca>
> *Cc:* cisco-voip voyp list <cisco-voip at puck.nether.net>
> *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 <lelio at uoguelph.ca> wrote:
>
>
>
> Does SIP allow for domain name substitution?
>
>
>
> By this I mean, instead of advertising or dialing
> coyote at phones.america.acmemanufacturing.com I want to use coyote at zing.com
>
>
>
> 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> | lelio at uoguelph.ca
>
>
>
> 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
> cisco-voip at puck.nether.net
> 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
> cisco-voip at puck.nether.net
> 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
> cisco-voip at puck.nether.net
>
> 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
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191004/01efeb02/attachment.htm>