Nick, sorry to hear that. Maybe this release will get added to the
compatibility matrix in the future after appropriate testing.
Dave, There's nothing wrong with this setup. It'll work.
However, if you're also using the router for SRST at a branch site, then
you will need to force the phones to failover on the ITSP interface
rather than the LAN voip interface.
Sreekanth
On Thursday 05 May 2016 03:23 AM, Dave Goodwin 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 <[email protected]
<mailto:[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]
<mailto:[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 <http://cisco.com> expires 3600
credentials username cisco password cisco realm cisco.com
<http://cisco.com>
authentication username cisco123 password 7 cisco123
sip-server dns:cisco.com <http://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] <mailto:[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]
<mailto:[email protected]>>
Date: 5/4/16 8:03 PM (GMT+05:30)
To: Brian Meade <[email protected] <mailto:[email protected]>>
Cc: Cisco VoIP Group <[email protected]
<mailto:[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://supportforums.cisco.com/blog/154506
On Wed, May 4, 2016 at 9:06 AM, Brian Meade
<[email protected] <mailto:[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]
<mailto:[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]
<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected] <mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
