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 <[email protected]> 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 <[email protected]> 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) < >> <[email protected]>[email protected]> 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 <[email protected]> >>> Date: 5/4/16 8:03 PM (GMT+05:30) >>> To: Brian Meade <[email protected]> >>> Cc: Cisco VoIP Group <[email protected]> >>> 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 <[email protected]> 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 < <[email protected]> >>>> [email protected]> 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 >>>>> [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
