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

Nick Barnett nicksbarnett at gmail.com
Wed May 4 16:22:57 EDT 2016


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
>>>>
>>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160504/56e9868c/attachment.html>


More information about the cisco-voip mailing list