[cisco-voip] SIP protocol question

Fri Jul 8 12:45:57 EDT 2016

B

Sent from my LG Mobile

Ed Leatherman <ealeatherman at gmail.com> wrote:

Hi Daniel,

That was how I read it as well - i just couldn't find an explanation of what the telephone-events package was actually for. Thanks for confirming that the rtp-nte is negotiated fine w/o it.

The issue that prompted me to start digging into this was that calls to the med center's help desk call center from certain phones (so far just 7960's) have not been able to connect to an agent. They get IVR audio but when the transfer happens it dies. So I am looking at a trace just from that. It is wild how many re-invites are happening on the med center side that CUBE just consumes.

note; I have midcall passthru media-change enabled, nothing else fancy. codec is locked in at g711u, and my dial peers have both kpml and rtp-nte enabled.

I'm seeing 3 things that are odd to me...
#1 at one point during the dialogue, there is a reinvite from med center that gets passed through cube, but I can't tell why as both CUCM and the med center sbc are continuing to advertise G711ulaw and rtp-nte.
#2 on the reinvite that gets passed through, it comes in as a DO from CUBE, and  CUCM is sending allow-events: presence,kpml (no telephone-events) along with its normal SDP offer including g711u and rtp-nte in the 200 OK. It's sending a=sendonly,
#3 CUBE ack's back to CUCM with a new SDP that includes NO rtp-nte for some reason. In the meantime, it has also advertised SDP back outside to the med center a similar SDP without rtp-nte and a=sendonly. So it removed rtp-nte and passed the sendonly back out to med center

At this point, CUCM does its own reinvite to establish sendrcv, however this does not get passed through and a few seconds later I get a BYE from the med center sbc.

I did find a bug that was suspiciously similar, CSCsw85869 however i'm not running T.38. I'm going to try and reproduce the issue without all the extra reinvites and maybe check with TAC on it. The trace i'm working from is hideous.

CUBE has some MTP resources available but doesn't appear to be inserting them at any point. My next point of investigation is to see if it's unable to for some reason. Since we've only reproduced the issue with a 7960 I didnt want to rule out something weird like that.

On Fri, Jul 8, 2016 at 10:35 AM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:
According to the RFC, the Allow-Events header is specifically used to convey events that a UA can support using the SUBSCRIBE method. Typically we’ll see KPML or Presence as a supported Allow-Event value, which makes sense since both of those events are initiated through SUBSCRIBE/NOTIFY transactions. I’m looking through sets of trace files where I know RTP-NTE is negotiated and have found multiple instances where DTMF was negotiated successfully (to RTP-NTE) without including telephone-events in the Allow-Events header.

What type of issues are you seeing with ReINVITEs?

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Ed Leatherman
Sent: Friday, July 08, 2016 9:18 AM
To: Cisco VOIP <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: [cisco-voip] SIP protocol question

Happy Friday!

This is probably a dumb basic question but my google-fu is failing me.

What exactly is the "telephone-event" event package used for in the allow-events: header? Must it be present?

I have been assuming it had to do with rtp-nte but that seems wrong since that's negotiated in the SDP.

I'm trying to integrate with our associated Medical Center with a SIP Trunk out of CUBE (IOS 15.4(3)M3) - they are running a mish-mash of Siemens PBX/SIP/Call Center stuff on their end. I'm having some weird stuff happen with reinvites when their system(s) transfer the call around and I'm trying to nail down everything I find that i'm not sure of... in one of the transactions the telephone-event is missing out of the allow-events in the invite.

Thanks!

--
Ed Leatherman

--
Ed Leatherman

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160708/c681dbe9/attachment.html>