Study question - SIP dial-peer on a CUBE to an ITSP - codec

Dieselboy · July 29, 2015, 01:00:26 AM

In this scenario what would happen? Is the system clever enough to work out or to invoke a transcoder to complete the call?

I have this setup:
SIP ITSP > [codec] > CUBE > SIP > CUCM 10.5 > SCCP/SIP > phones

If I chose a codec between the ITSP and the SIP dial-peer on the CUBE to be example G729 or GSM, this will work between the CUBE and the ITSP because both ends support it. If my phones which currently use G711 for internal calls place a call to the PSTN what happens? I believe if the handset supports G729 then G729 will be used between the handset and the ITSP, no transcoder needed. If I select the ITSP to use GSM and the handset supports GSM then again like G729 no transcoder is needed.
However, if the handset does not support GSM then will CUCM invoke the transcoder listed in the media resource group to complete the call? My assumption is that it will but just wanted to ask the question.

deanwebb · July 29, 2015, 09:08:48 AM

Not knowing anything at all about the correct answer, but still wanting to help, I'll ask...

Why do you assume that it will?

routerdork · July 29, 2015, 09:32:36 AM

Been awhile since I had to deal with that part of VoIP but I believe you are correct.

NetworkGroover · July 29, 2015, 12:44:09 PM

God I'm glad I don't deal with voice.

Dieselboy · July 29, 2015, 09:28:25 PM

Quote from: deanwebb on July 29, 2015, 09:08:48 AM
Not knowing anything at all about the correct answer, but still wanting to help, I'll ask...

Why do you assume that it will?

Because I think the system is designed that way. I did once ask another silly question when I had just passed the CCNA exam and was studying for the CCNP switching BCMSN. The question was something along the lines of, what makes a router or switch actually push the packets, ie what makes them actually write the packet onto the wire on the egress interface. Of course the answer is, that is what they are designed to do but at the time I don't know if I was confused or amazed.

Back to the question (And bearing in mind I'm only on the 2nd CCNP Voice exam book)
If I place an internal call between two desk phones, the codec is g711. If I place a call to the PSTN my codec on my phone is now G.729. I can see the codec in use on the handset if I go to show call stats. This is because the ITSP is set to use g729 and the handset supports it. I'll try and set up a test with the ITSP using GSM, and make sure my handset does not support GSM and see what happens. I'll let you guys know.

PS I like dealing with voice. I'd rather do this than mess about with SSL certificates, trust relationships or IPS. Although I still haven't got Source Fire for our ASA's and I really want to do that.

Cheers,

deanwebb · July 29, 2015, 10:19:47 PM

I plan to get SourceFire training later this year or early next year. I'll let you know how it goes.

Dieselboy · July 30, 2015, 12:19:28 AM

I would have had sourcefire months ago, but I took on an ASA 5515X pair as a try and buy and I was mis-sold content security. ASA CX is end of life next month and it didn't work. When a device inside our network done a port scan it caused the ASA CX modules to crash and fail over. Not only that but other parts of the software simply didn't work - waste of time.
So, I accepted the ASAs but wanted them to re-quote for source fire, however their quotes are wrong and they want to charge double the quote we previously had and re-ship 2 ASAs. I'm waiting for our account manager to get back to me at our reseller for around 3 months now. If I email him about another topic he will reply, but if I email him directly about the ASAs I'm ignored. And as such we currently have ASA's we've not paid for, for around 9 months. I had better chase this up again today - doing it now. I want to pay for the ASAs but I also want sourcefire. But I need to try it first to do a proof of concept. I think it's causing them difficulties :s

NetworkGroover · July 30, 2015, 12:27:40 AM

Quote from: Dieselboy on July 30, 2015, 12:19:28 AM
I would have had sourcefire months ago, but I took on an ASA 5515X pair as a try and buy and I was mis-sold content security. ASA CX is end of life next month and it didn't work. When a device inside our network done a port scan it caused the ASA CX modules to crash and fail over. Not only that but other parts of the software simply didn't work - waste of time.
So, I accepted the ASAs but wanted them to re-quote for source fire, however their quotes are wrong and they want to charge double the quote we previously had and re-ship 2 ASAs. I'm waiting for our account manager to get back to me at our reseller for around 3 months now. If I email him about another topic he will reply, but if I email him directly about the ASAs I'm ignored. And as such we currently have ASA's we've not paid for, for around 9 months. I had better chase this up again today - doing it now. I want to pay for the ASAs but I also want sourcefire. But I need to try it first to do a proof of concept. I think it's causing them difficulties :s

Wow dude - that's utter garbage. Can't they do a CPOC or something?

wintermute000 · July 30, 2015, 06:48:06 AM

Are you sure cucm supports gsm. You'd need a transcoder with gsm configured in the mrgl of the sip trunk or handset, can't remember the mrgl logic but there is a sequence that determines who invokes transcoding.
old hack not in book, if cube supports gsm which is no lol but logic is register a transcoder to cube itself like a cme then cube will invokes transcoding between the call legs without needing cucm, old trick used to achieve in band dtmf as again shitty cucm does not do in band dtmf.
Maybe v10 does do gsm my xp ended with 8.6
I'll sell you my ccnp voice for a pineapple lol I'm so scarred and it's chewed up so much of my career I could have spent doing mpls or data center switching instead [emoji14]

wintermute000 · July 30, 2015, 06:56:36 AM

Also: re: next generation firewalls, go Palo or go home. My mob can't handle the volume of demand, it's as hot as any security product I've ever seen.

deanwebb · July 30, 2015, 08:16:02 AM

Quote from: wintermute000 on July 30, 2015, 06:56:36 AM
Also: re: next generation firewalls, go Palo or go home. My mob can't handle the volume of demand, it's as hot as any security product I've ever seen.

We got a million ASAs that aren't EoL, so getting the SourceFire plugin is the easiest, peasiest way to not spend a gazillion dollars on upgrading hardware.

NetworkGroover · July 30, 2015, 10:06:09 AM

Quote from: wintermute000 on July 30, 2015, 06:48:06 AM
Are you sure cucm supports gsm. You'd need a transcoder with gsm configured in the mrgl of the sip trunk or handset, can't remember the mrgl logic but there is a sequence that determines who invokes transcoding.
old hack not in book, if cube supports gsm which is no lol but logic is register a transcoder to cube itself like a cme then cube will invokes transcoding between the call legs without needing cucm, old trick used to achieve in band dtmf as again shitty cucm does not do in band dtmf.
Maybe v10 does do gsm my xp ended with 8.6
I'll sell you my ccnp voice for a pineapple lol I'm so scarred and it's chewed up so much of my career I could have spent doing mpls or data center switching instead [emoji14]

NetworkGroover · July 30, 2015, 10:08:38 AM

Quote from: wintermute000 on July 30, 2015, 06:56:36 AM
Also: re: next generation firewalls, go Palo or go home. My mob can't handle the volume of demand, it's as hot as any security product I've ever seen.

Yep - definitely considered best-of-breed by many.

Dieselboy · July 31, 2015, 01:59:01 AM

I'm in Western Australia, so it will be 10 or 20 years before Palo make its way here. Although my old company in London have been using Palo for ages, and they support VTI tunnels to Cisco 3900 ISRs for OSPF over IPSEC. I've never even seen one

Regarding codec, our 2921 does do GSM. What you said makes sense regarding the transcoder added to the mrgl of the trunk, so I'll check that over.

wintermute000 · July 31, 2015, 11:46:12 PM

1.) Thanks for the update, I'll add the GSM knowledge to the back of my mind
2.) You WILL get an exam question on 'which device's MGRL is getting invoked in this call scenario' type question so make sure you read up on the CUCM logic

If I remember correctly, in an outbound call, in your scenario, the phone will offer its compatible codecs, the CUBE will reply with one, that's that leg. The CUBE will then offer compatible codecs to the provider, vice versa, then if transcoding is invoked, its the trunk's MRGL. I believe there is a difference if the sequence is reversed and if its say internal calling (i.e. calling or called phone invokes transcoder?).
3.) If you're keen on Palos, let me know and I'm sure something can be arranged, even if all that happens is that you have a chat with the Palo SE in Perth - we're an official partner but in this scenario I'm not sure if we'd bring the vendor in first or go in ourselves, nonetheless, ping me if curious. DID YOU KNOW (tm): there is one button you can click and the FW tells you all rules that haven't been hit since uptime