[cisco-voip] Authenticating sip trunk to ITSP from CUBE?

Nick Barnett nicksbarnett at gmail.com
Wed Jun 1 13:53:27 EDT 2016 

I just thought I would update with how I got this working. It was a multi
staged "fix." I rewrote the entire dial plan to use e164 pattern maps and
SRV records. This reduced my dial peer count from 150+ to less than 20.
Then I took the INSIDE dial peers and bound them at the DP level to the
inside interface. OUTSIDE PSTN facing DPs got bound to the outside
interface.

At this point, register requests were sourcing from the external interface
IP address and not the external VIP (I'm using CUBE HA).

To fix that, I placed a global bind in voice service voip to the outside
interface. This made the REGISTER requests source from the external VIP...
but it broke other stuff.

With the internal DPs bound inside and the external DPs bound outside...
the SIP REGISTER events were now using the global bind... but my SIP
OPTIONS pings from CUCM were also answering from that public IP on the
outside interface... so my SIP trunks to the cube from CUCM went out of
service.

I added voice class SIP URIs to my internal CUCM dial peers so that the
inside interface would answer SIP OPTIONS pings.

I put my credentials lines in sip-ua and auth lines in the external DPs.

Everything is up and running.

Thanks for everyone's help and suggestions.

On Wed, May 4, 2016, 4:54 PM Dave Goodwin <dave.goodwin at december.net> wrote:

> Is there anything wrong with adding voice-class sip bind commands to ALL
> the voip dial-peers, and then set the global binding to the interface that
> faces the ITSP requiring authentication (since it seems sip-ua REGISTER
> messages use the global bind)?
>
> -Dave
>
> On Wed, May 4, 2016 at 4:22 PM, Nick Barnett <nicksbarnett at gmail.com>
> wrote:
>
>> Thanks for everybody's ideas.
>>
>> Unfortunately, 15.6 is OUT because it is not on the CVP 10.0
>> compatibility matrix :(
>>
>> I'm going to look at using multiple registrars and see if I can trick it
>> into behaving... if that doesn't work, I guess I'll have to remove my
>> global binding...
>>
>>
>> On Wed, May 4, 2016 at 11:35 AM, Sreekanth <sreenara at cisco.com> wrote:
>>
>>> Yes, sip-ua tells CUBE to send REGISTER messages towards a Registrar
>>> server globally with the authentication and credential parameters. These
>>> REGISTER messages will be bound to the interface that is bound under voice
>>> service voip -> sip. However, in the 15.6(2)T version, the tenant
>>> configurations under the dial-peers will instruct the CUBE to send out
>>> REGISTER messages.
>>>
>>> I just checked with the router in my lab and actually, option 2 won't be
>>> possible. It won't instruct the CUBE to send out REGISTER messages. It will
>>> only instruct the CUBE to add authentication credentials and realm settings
>>> when sending out the INVITE messages towards the session target configured
>>> under the dial-peer.
>>>
>>> You will have to go with option 1.
>>> *1. Create the voice class tenant for the SIP trunk to ITSP and bind it
>>> with the right interface.*
>>> voice class tenant 1
>>>   registrar dns:cisco.com expires 3600
>>>   credentials username cisco password cisco realm cisco.com
>>>   authentication username cisco123 password 7 cisco123
>>>   sip-server dns:cisco.com
>>>   bind control source-interface GigabitEthernet0/2
>>>   bind media source-interface GigabitEthernet0/2
>>>   early-offer forced
>>>
>>> *2. Apply the voice class tenant to the dial-peer. Create specific
>>> dial-peers towards ITSP.*
>>> dial-peer voice X voip
>>>  voice-class sip tenant 1
>>>
>>> When this is done, CUBE will send REGISTER messages as well towards this
>>> ITSP with the traffic bound to gig0/2.
>>> This way you can have multiple ITSP trunks on 1 CUBE.
>>>
>>> Sreekanth
>>>
>>>
>>>
>>>
>>> On Wednesday 04 May 2016 09:29 PM, Nick Barnett wrote:
>>>
>>> I'm currently on c3900e-universalk9-mz.SPA.153-3.M6, but can totally
>>> upgrade. Was actually planning on going to 15.4 this weekend. Jumping 3
>>> versions kind of scares me, so maybe staging is in order.
>>>
>>> *I do have some limited auth commands on the dial peer, if this is what
>>> you were talking about... but I don't think it applies in this scenario. I
>>> don't have any options for credentials:*
>>> CUBE(config-dial-peer)#voice-class sip authenticate ?
>>>   redirecting-number  Use redirecting number credentials while
>>> authenticating
>>>
>>> CUBE(config-dial-peer)#voice-class sip cred
>>> CUBE(config-dial-peer)#voice-class sip c?
>>>   call-route  calltype-video  conn-reuse  copy-list
>>>
>>> *There is also the registration commands:*
>>> CUBE(config-dial-peer)#voice-class sip registration ?
>>>   passthrough  SIP Registration Passthrough Options
>>>
>>> CUBE(config-dial-peer)#voice-class sip registration passthrough ?
>>>   dynamic          SIP Registration Use dynamic Registrar Details
>>> (default)
>>>   local-fallback   Local Fallback - (e2e)
>>>   rate-limit       SIP Registration pass-through rate-limit Options
>>>   reg-sync         Registration Sync - send REGISTER when registrar up
>>> (p2p)
>>>   registrar-index  Registrar Index(s) used for registration passthrough
>>>   static           SIP Registration Use static Registrar Details
>>>   system           Use global registration passthrough CLI setting
>>>   <cr>
>>>
>>> *I tried using the system passthrough setting, but it did not work.*
>>>
>>> *I need to make sure I understand what is actually happening.*
>>>
>>> *I don't think the CUBE is even looking at dial-peers for REGISTER
>>> messages. Am I correct?  If so, no amount of dial peer settings is going to
>>> make any difference here... unless there is a way to create a dial-peer
>>> that will intercept REGISTER messages. I believe it is using the REALM
>>> settings in the credentials and authentication strings (that I entered into
>>> sip-ua). And sip-ua is using the global bind settings I set within voice
>>> service voip -> SIP (which are set to the inside interface).*
>>>
>>> *Please set me straight!*
>>>
>>> Thanks,
>>> Nick
>>>
>>> On Wed, May 4, 2016 at 10:37 AM, Sreekanth Narayanan (sreenara) <
>>> <sreenara at cisco.com>sreenara at cisco.com> wrote:
>>>
>>>> What IOS version are you running on the CUBE? I can think of a couple
>>>> of things.
>>>> 1. In 15.6(2)T, a new feature has been introduced called multi-tenant
>>>> where you can configure separate voice class tenants. Each tenant can have
>>>> separate authentication mutually exclusive to one another and can be bound
>>>> to different interfaces.
>>>>
>>>> 2. In your current IOS, check if you are able to configure the
>>>> authentication and credential commands at the dial peer level. I am not
>>>> sure which IOS had this introduced but it is worth a try.
>>>>
>>>>
>>>>
>>>> Sreekanth
>>>>
>>>> Sent from a phone.
>>>>
>>>>
>>>> -------- Original message --------
>>>> From: Nick Barnett <nicksbarnett at gmail.com>
>>>> Date: 5/4/16 8:03 PM (GMT+05:30)
>>>> To: Brian Meade <bmeade90 at vt.edu>
>>>> Cc: Cisco VoIP Group <cisco-voip at puck.nether.net>
>>>> Subject: Re: [cisco-voip] Authenticating sip trunk to ITSP from CUBE?
>>>>
>>>> I'm binding control and media to my inside interface:
>>>>
>>>> sip
>>>>
>>>>   bind control source-interface GigabitEthernet0/0
>>>>   bind media source-interface GigabitEthernet0/0
>>>>
>>>> I suspect this is the issue... is there any way to make the REGISTER
>>>> messages come from the outside gi0/1 interface?
>>>>
>>>> The reason I'm binding to inside is that we have a a very fluid
>>>> internal network. I have to make and modify internal dial peers almost
>>>> daily.  When I need to create a dial peer and put the bind statements on
>>>> the dial peer, it won't bind properly since there are active SIP calls on
>>>> the CUBE... so I bound it globally. My external dial peers rarely change,
>>>> so I bind those directly to gi0/1 (on the DP).
>>>>
>>>> I was under the impression that REGISTER events can take place without
>>>> a dial peer... but is there a way to, i dunno, make a dial peer for
>>>> register messages?  Can I use SIP profile magic to get it working as is?
>>>>
>>>> I found this article which is pretty much exactly what I'm dealing
>>>> with, but it doesn't mention REGISTER at all...
>>>>
>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__supportforums.cisco.com_blog_154506&d=CwMFAg&c=M-KQspD_LQogCbR-BWCHOaeDEPOhF8vWqHZTaiwxT3c&r=T9uVLZucbHG2NKKKzOrp-o5cpdReHj02PkJJsCVkgfwcv7S0R5lDeFJg2VRbiNih&m=UIAzGDQs8RCZld9kCbExwqpJhTgzpDVwM0k8_I7JRqU&s=jZN-R2pRsZOWN3r5is-aSivDlf9hqddUzDIoOWRWc3E&e=>
>>>> https://supportforums.cisco.com/blog/154506
>>>>
>>>>
>>>>
>>>> On Wed, May 4, 2016 at 9:06 AM, Brian Meade <bmeade90 at vt.edu> wrote:
>>>>
>>>>> Do you already have the SIP bind under voice service voip?
>>>>> voice service voice
>>>>>  sip
>>>>>   bind all source-interface FastEthernet0
>>>>>
>>>>> On Wed, May 4, 2016 at 9:58 AM, Nick Barnett <
>>>>> <nicksbarnett at gmail.com>nicksbarnett at gmail.com> wrote:
>>>>>
>>>>>> I've never dealt with an authenticated SIP trunk before and I'm
>>>>>> having some issues. I was wondering if anyone has had a similar experience.
>>>>>> I already have 2 SIP trunks from ITSP-1 that do NOT require authentication.
>>>>>> These are working fine and have been for years.
>>>>>>
>>>>>> We are adding ITSP-2 and their SIP service DOES require auth.  I've
>>>>>> followed their integration guide (which left a lot to be desired) and their
>>>>>> acceptance team is telling me my auth is coming from our private class A
>>>>>> address.
>>>>>>
>>>>>> Our CUBE is in HA with an inside (10.x.x.x) and outside (public) IP
>>>>>> address. They are seeing REGISTER messages sourcing the inside VIP.
>>>>>>
>>>>>> I was looking around for an auth BIND statement or something like
>>>>>> that, but I haven't had any luck. Any pointers?
>>>>>>
>>>>>> Thanks,
>>>>>> Nick
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20160601/311ce495/attachment.html>

More information about the cisco-voip mailing list