[cisco-voip] MOH with CUBE

[Ed Leatherman]

I'm working on getting a SIP trunk with an ITSP fully functional. I can get
basic calls ok but Unicast MOH is not working out - no audio. Going
off-hold i get the call audio back.

Quick packet cap on the CUBE confirms i'm getting MOH packets from CUCM but
they don't make it across CUBE out to the SP.

For the re-INVITE to get the music audio, CUCM is sending SDP with:
m=audio 4000 RTP/AVP 0

From the packet cap, the audio packets are not being sourced from port 4000
- they are coming in from ephemeral ports. Could this be causing an issue
with CUBE not translating the streams?

The reason I ask is that I noticed a bug out there CSCtb32219
<https://www.cisco.com/cisco/psn/bssprt/bss?searchType=bstbugidsearch&page=bstBugDetail&BugID=CSCtb32219>
for
ASR1K which seems close, in my case this is a 4431 (Also ios-xe) running
15.5(1)S. Anyone run into that? The workaround is to enable duplex
streaming in CUCM, which seems a little goofy.

I dont feel like I have anything special configured on CUBE:
voice service voip
ip address trusted list
ipv4 blahblahblah
address-hiding
allow-connections sip to sip
no supplementary-service sip refer
fax protocol pass-through g711ulaw
sip
pass-thru content sdp
sip-profiles 100
!

dialpeers all have
!

dtmf-relay rtp-nte
codec g711ulaw
no vad


Thanks!



--
Ed Leatherman

[Ed Leatherman]

Hi Anthony,

For #2.. Its just there because the sp's integration guide had it in there-
I'll try it tomorrow without and see if it fixes it, what you say makes
sense. thanks!

On Mon, Feb 8, 2016, 5:49 PM Anthony Holloway <
avholloway+cisco-***@gmail.com> wrote:

> I just wanted to comment on two things:
>
> 1) The port 4000 thing. CUCM does this to just give a port number, it
> doesn't actually use it. I wouldn't be looking to hard at that as a
> problem.
>
> *4000 - 4005 / TCP*
> *These ports are used as phantom Real-Time Transport Protocol (RTP) and
> Real-Time Transport Control Protocol (RTCP) ports for audio, video and data
> channel when Cisco Unified Communications Manager does not have ports for
> these media.*
> *Source: TCP and UDP Port Usage Guide for Cisco Unified Communications
> Manager, Release 10.0(1)
> <http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/port/10_0_1/CUCM_BK_T537717B_00_tcp-port-usage-guide-100.html>*
>
>
> With the way SDP works, if the offered port is 4000, and the media
> attribute a=sednonly is present, then the port is essentially ignored.
> Hence, a half duplex stream, and not full duplex.
>
> 2) Why are you using this command "pass-thru content sdp" As far as I am
> aware, that command will pass thru SDP from CUCM directly to the ITSP. Is
> that something you need? Typically, CUBE is your demarc between your
> enterprise network and the service provider, and as such, you don't pass
> through anything directly. If you don't know why that's there, then I
> would recommend removing it and re-testing your MOH scenario.
>
> A similar command you might want to run is to suppress all of the chatter
> CUCM will send to CUBE that really has no business going out to the ITSP,
> but keeping the important messages, such as mid-call media changes.
>
> voice service voip
> sip
> midcall-signaling passthru media-change
> !
>
> As far as your 4K router and the closeness of the AS1K defect, I really
> don't know.
>
> On Mon, Feb 8, 2016 at 3:47 PM, Ed Leatherman <***@gmail.com>
> wrote:
>
>> I'm working on getting a SIP trunk with an ITSP fully functional. I can
>> get basic calls ok but Unicast MOH is not working out - no audio. Going
>> off-hold i get the call audio back.
>>
>> Quick packet cap on the CUBE confirms i'm getting MOH packets from CUCM
>> but they don't make it across CUBE out to the SP.
>>
>> For the re-INVITE to get the music audio, CUCM is sending SDP with:
>> m=audio 4000 RTP/AVP 0
>>
>> From the packet cap, the audio packets are not being sourced from port
>> 4000 - they are coming in from ephemeral ports. Could this be causing an
>> issue with CUBE not translating the streams?
>>
>> The reason I ask is that I noticed a bug out there CSCtb32219
>> <https://www.cisco.com/cisco/psn/bssprt/bss?searchType=bstbugidsearch&page=bstBugDetail&BugID=CSCtb32219> for
>> ASR1K which seems close, in my case this is a 4431 (Also ios-xe) running
>> 15.5(1)S. Anyone run into that? The workaround is to enable duplex
>> streaming in CUCM, which seems a little goofy.
>>
>> I dont feel like I have anything special configured on CUBE:
>> voice service voip
>> ip address trusted list
>> ipv4 blahblahblah
>> address-hiding
>> allow-connections sip to sip
>> no supplementary-service sip refer
>> fax protocol pass-through g711ulaw
>> sip
>> pass-thru content sdp
>> sip-profiles 100
>> !
>>
>> dialpeers all have
>> !
>>
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> no vad
>>
>>
>> Thanks!
>>
>>
>>
>> --
>> Ed Leatherman
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-***@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>

[Erick Bergquist]

Have you tried to enable the duplex streaming knob yet? It gets
music on hold working where I've encountered this problem with vanilla
and not fancy SIP configurations.

Erick


On Mon, Feb 8, 2016 at 5:12 PM, Ed Leatherman <***@gmail.com> wrote:
> Hi Anthony,
>
> For #2.. Its just there because the sp's integration guide had it in there-
> I'll try it tomorrow without and see if it fixes it, what you say makes
> sense. thanks!
>
>
> On Mon, Feb 8, 2016, 5:49 PM Anthony Holloway
> <avholloway+cisco-***@gmail.com> wrote:
>>
>> I just wanted to comment on two things:
>>
>> 1) The port 4000 thing. CUCM does this to just give a port number, it
>> doesn't actually use it. I wouldn't be looking to hard at that as a
>> problem.
>>
>> 4000 - 4005 / TCP
>> These ports are used as phantom Real-Time Transport Protocol (RTP) and
>> Real-Time Transport Control Protocol (RTCP) ports for audio, video and data
>> channel when Cisco Unified Communications Manager does not have ports for
>> these media.
>> Source: TCP and UDP Port Usage Guide for Cisco Unified Communications
>> Manager, Release 10.0(1)
>>
>>
>> With the way SDP works, if the offered port is 4000, and the media
>> attribute a=sednonly is present, then the port is essentially ignored.
>> Hence, a half duplex stream, and not full duplex.
>>
>> 2) Why are you using this command "pass-thru content sdp" As far as I am
>> aware, that command will pass thru SDP from CUCM directly to the ITSP. Is
>> that something you need? Typically, CUBE is your demarc between your
>> enterprise network and the service provider, and as such, you don't pass
>> through anything directly. If you don't know why that's there, then I would
>> recommend removing it and re-testing your MOH scenario.
>>
>> A similar command you might want to run is to suppress all of the chatter
>> CUCM will send to CUBE that really has no business going out to the ITSP,
>> but keeping the important messages, such as mid-call media changes.
>>
>> voice service voip
>> sip
>> midcall-signaling passthru media-change
>> !
>>
>> As far as your 4K router and the closeness of the AS1K defect, I really
>> don't know.
>>
>> On Mon, Feb 8, 2016 at 3:47 PM, Ed Leatherman <***@gmail.com>
>> wrote:
>>>
>>> I'm working on getting a SIP trunk with an ITSP fully functional. I can
>>> get basic calls ok but Unicast MOH is not working out - no audio. Going
>>> off-hold i get the call audio back.
>>>
>>> Quick packet cap on the CUBE confirms i'm getting MOH packets from CUCM
>>> but they don't make it across CUBE out to the SP.
>>>
>>> For the re-INVITE to get the music audio, CUCM is sending SDP with:
>>> m=audio 4000 RTP/AVP 0
>>>
>>> From the packet cap, the audio packets are not being sourced from port
>>> 4000 - they are coming in from ephemeral ports. Could this be causing an
>>> issue with CUBE not translating the streams?
>>>
>>> The reason I ask is that I noticed a bug out there CSCtb32219 for ASR1K
>>> which seems close, in my case this is a 4431 (Also ios-xe) running 15.5(1)S.
>>> Anyone run into that? The workaround is to enable duplex streaming in CUCM,
>>> which seems a little goofy.
>>>
>>> I dont feel like I have anything special configured on CUBE:
>>> voice service voip
>>> ip address trusted list
>>> ipv4 blahblahblah
>>> address-hiding
>>> allow-connections sip to sip
>>> no supplementary-service sip refer
>>> fax protocol pass-through g711ulaw
>>> sip
>>> pass-thru content sdp
>>> sip-profiles 100
>>> !
>>>
>>> dialpeers all have
>>> !
>>>
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> no vad
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> --
>>> Ed Leatherman
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-***@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-***@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

[Ryan Huff]

How does one pee on an onion? .... (clearly, I know you meant PEELING and I am in no way grammar police).

I just got a sincere and much needed chuckle from this, "In my experience, turning up SIP services is like peeing an onion ...".

All in good fun Anthony ;)

Sent from my iPhone

On Feb 9, 2016, at 12:12 PM, Anthony Holloway <avholloway+cisco-***@gmail.com<mailto:avholloway+cisco-***@gmail.com>> wrote:

In my experience, turning up SIP services is like peeing an onion

[Ryan Huff]

All in good fun, I can't tell you how many I have made :). Spot on advice .. Keepin' it 100!

Sent from my iPhone

On Feb 9, 2016, at 12:25 PM, Anthony Holloway <avholloway+cisco-***@gmail.com<mailto:avholloway+cisco-***@gmail.com>> wrote:

I know....I saw it after I sent it. Mailing lists have their drawbacks, and editing a post after submitting it, is one of them.

On Tue, Feb 9, 2016 at 11:19 AM, Ryan Huff <***@outlook.com<mailto:***@outlook.com>> wrote:
How does one pee on an onion? .... (clearly, I know you meant PEELING and I am in no way grammar police).

I just got a sincere and much needed chuckle from this, "In my experience, turning up SIP services is like peeing an onion ...".

All in good fun Anthony ;)

Sent from my iPhone

On Feb 9, 2016, at 12:12 PM, Anthony Holloway <avholloway+cisco-***@gmail.com<mailto:avholloway+cisco-***@gmail.com>> wrote:

In my experience, turning up SIP services is like peeing an onion

[Ed Leatherman]

When I first read it I thought he just meant he hated it that much :)

Awesome write-up though Anthony. Now that I see what that midcall
signalling setting is actually doing, i'm a fan.

re: Troubleshooting this stuff.. I'm trying to use "show call active voice
[brief]" to see calls in service; none of the packet counters seem to work
though... dur 00:01:16 tx:0/0 rx:0/0. That seemed to be the command to use
based on docs I was looking at but i'm not getting any moving counters. Is
there a different command i'm not finding that will show me these? This one
is listing each call leg which I kinda like seeing.

On Tue, Feb 9, 2016 at 12:19 PM, Ryan Huff <***@outlook.com> wrote:

> How does one pee on an onion? .... (clearly, I know you meant PEELING and
> I am in no way grammar police).
>
> I just got a sincere and much needed chuckle from this, "*In my
> experience, turning up SIP services is like peeing an onion ...*".
>
> All in good fun Anthony ;)
>
> Sent from my iPhone
>
> On Feb 9, 2016, at 12:12 PM, Anthony Holloway <
> avholloway+cisco-***@gmail.com> wrote:
>
> In my experience, turning up SIP services is like peeing an onion
>
>


--
Ed Leatherman

[Ed Leatherman]

Thanks Anthony, +1 for the appropriate youtube.

On Tue, Feb 9, 2016 at 8:40 PM, Anthony Holloway <
avholloway+cisco-***@gmail.com> wrote:

> It's funny you should mention packet counters on your IOS XE platform, as
> I was just watching Paul Giralt's talk on SIP troubleshooting (worth the
> entire watch, multiple times over). Check out the video at precisely the
> 1:00:44 mark, linked below. Your welcome.
> <https://www.youtube.com/watch?v=oYZD1sQBdlE> ;)
>
> BRKUCC-2932 - Troubleshooting SIP with Cisco Unified Communications (2015
> San Diego) - 2 Hours
> <https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=83773&backBtn=true>
>
> On Tue, Feb 9, 2016 at 11:28 AM, Ed Leatherman <***@gmail.com>
> wrote:
>
>> When I first read it I thought he just meant he hated it that much :)
>>
>> Awesome write-up though Anthony. Now that I see what that midcall
>> signalling setting is actually doing, i'm a fan.
>>
>> re: Troubleshooting this stuff.. I'm trying to use "show call active
>> voice [brief]" to see calls in service; none of the packet counters seem to
>> work though... dur 00:01:16 tx:0/0 rx:0/0. That seemed to be the command to
>> use based on docs I was looking at but i'm not getting any moving counters.
>> Is there a different command i'm not finding that will show me these? This
>> one is listing each call leg which I kinda like seeing.
>>
>> On Tue, Feb 9, 2016 at 12:19 PM, Ryan Huff <***@outlook.com> wrote:
>>
>>> How does one pee on an onion? .... (clearly, I know you meant PEELING
>>> and I am in no way grammar police).
>>>
>>> I just got a sincere and much needed chuckle from this, "*In my
>>> experience, turning up SIP services is like peeing an onion ...*".
>>>
>>> All in good fun Anthony ;)
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 9, 2016, at 12:12 PM, Anthony Holloway <
>>> avholloway+cisco-***@gmail.com> wrote:
>>>
>>> In my experience, turning up SIP services is like peeing an onion
>>>
>>>
>>
>>
>> --
>> Ed Leatherman
>>
>
>


--
Ed Leatherman

[Ed Leatherman]

Anthony,

Removing the sdp passthru did the trick; now I need to take some debugs and
compare so maybe i can understand what was passing thru causing the
problem. I'll try that other command you suggested too. I have an exact
duplicate of this trunk to turn up in a few weeks so I'm happy to learn
this stuff now.

Erick - I didn't try the duplex media streaming - wanted to see if there
was something I could do locally on CUBE instead of making a cluster-wide
change like that... but I was close to trying it.

Thanks!!

Ed

On Mon, Feb 8, 2016 at 5:49 PM, Anthony Holloway <
avholloway+cisco-***@gmail.com> wrote:

> I just wanted to comment on two things:
>
> 1) The port 4000 thing. CUCM does this to just give a port number, it
> doesn't actually use it. I wouldn't be looking to hard at that as a
> problem.
>
> *4000 - 4005 / TCP*
> *These ports are used as phantom Real-Time Transport Protocol (RTP) and
> Real-Time Transport Control Protocol (RTCP) ports for audio, video and data
> channel when Cisco Unified Communications Manager does not have ports for
> these media.*
> *Source: TCP and UDP Port Usage Guide for Cisco Unified Communications
> Manager, Release 10.0(1)
> <http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/port/10_0_1/CUCM_BK_T537717B_00_tcp-port-usage-guide-100.html>*
>
>
> With the way SDP works, if the offered port is 4000, and the media
> attribute a=sednonly is present, then the port is essentially ignored.
> Hence, a half duplex stream, and not full duplex.
>
> 2) Why are you using this command "pass-thru content sdp" As far as I am
> aware, that command will pass thru SDP from CUCM directly to the ITSP. Is
> that something you need? Typically, CUBE is your demarc between your
> enterprise network and the service provider, and as such, you don't pass
> through anything directly. If you don't know why that's there, then I
> would recommend removing it and re-testing your MOH scenario.
>
> A similar command you might want to run is to suppress all of the chatter
> CUCM will send to CUBE that really has no business going out to the ITSP,
> but keeping the important messages, such as mid-call media changes.
>
> voice service voip
> sip
> midcall-signaling passthru media-change
> !
>
> As far as your 4K router and the closeness of the AS1K defect, I really
> don't know.
>
> On Mon, Feb 8, 2016 at 3:47 PM, Ed Leatherman <***@gmail.com>
> wrote:
>
>> I'm working on getting a SIP trunk with an ITSP fully functional. I can
>> get basic calls ok but Unicast MOH is not working out - no audio. Going
>> off-hold i get the call audio back.
>>
>> Quick packet cap on the CUBE confirms i'm getting MOH packets from CUCM
>> but they don't make it across CUBE out to the SP.
>>
>> For the re-INVITE to get the music audio, CUCM is sending SDP with:
>> m=audio 4000 RTP/AVP 0
>>
>> From the packet cap, the audio packets are not being sourced from port
>> 4000 - they are coming in from ephemeral ports. Could this be causing an
>> issue with CUBE not translating the streams?
>>
>> The reason I ask is that I noticed a bug out there CSCtb32219
>> <https://www.cisco.com/cisco/psn/bssprt/bss?searchType=bstbugidsearch&page=bstBugDetail&BugID=CSCtb32219> for
>> ASR1K which seems close, in my case this is a 4431 (Also ios-xe) running
>> 15.5(1)S. Anyone run into that? The workaround is to enable duplex
>> streaming in CUCM, which seems a little goofy.
>>
>> I dont feel like I have anything special configured on CUBE:
>> voice service voip
>> ip address trusted list
>> ipv4 blahblahblah
>> address-hiding
>> allow-connections sip to sip
>> no supplementary-service sip refer
>> fax protocol pass-through g711ulaw
>> sip
>> pass-thru content sdp
>> sip-profiles 100
>> !
>>
>> dialpeers all have
>> !
>>
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> no vad
>>
>>
>> Thanks!
>>
>>
>>
>> --
>> Ed Leatherman
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-***@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>


--
Ed Leatherman