[cisco-voip] SIP protocol question

[Ed Leatherman]

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> 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] *On Behalf
> Of *Ed Leatherman
> *Sent:* Friday, July 08, 2016 9:18 AM
> *To:* Cisco VOIP <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160708/5c2c9191/attachment.html>