[cisco-voip] MOH with CUBE

[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-voip at 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 <ealeatherman at 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-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>


-- 
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160209/d1114b7d/attachment.html>