[cisco-voip] question(s) about SIP early media

[Brian Meade (brmeade)]

So in this case CUCM sends the 183 Session Progress with SDP.  We would then expect the Vidyo server to respond with a Prack depending upon whether or not Rel1XX is in the required header of the 183 Session Progress.

Brian

From: Ed Leatherman [mailto:ealeatherman at gmail.com]
Sent: Tuesday, October 15, 2013 9:49 AM
To: Brian Meade (brmeade)
Cc: Cisco VOIP
Subject: Re: [cisco-voip] question(s) about SIP early media

Hi Brian,

Here's what the signalling looks like, apologies for the formatting.

No.     Delta       Time        Source                Destination           Protocol Info
      1 0.000000    0.000000    Vidyo Server          CUCM                  SIP/SDP  Request: INVITE sip:83045551212 at CUCM        | , with session description
      2 0.001193    0.001193    CUCM                  Vidyo Server          SIP      Status: 100 Trying |
             RTP from MTP to Vidyo starts here
      9 0.273383    0.274576    CUCM                  Vidyo Server          SIP/SDP  Status: 183 Session Progress | , with session description
     47 0.751382    1.025958    CUCM                  Vidyo Server          SIP      Request: UPDATE sip:Vidyo Server  :50600;transport=UDP |
     48 0.000829    1.026787    Vidyo Server          CUCM                  SIP      Status: 200 OK |
    707 13.100773   14.127560   Vidyo Server          CUCM                  SIP      Request: CANCEL sip:83045551212 at CUCM       :5060 |
    708 0.000478    14.128038   CUCM                  Vidyo Server          SIP      Status: 200 OK |
    710 0.004368    14.132406   CUCM                  Vidyo Server          SIP      Status: 487 Request Cancelled |
    711 0.000756    14.133162   Vidyo Server          CUCM                  SIP      Request: ACK sip:83045551212 at CUCM        |

On Tue, Oct 15, 2013 at 8:25 AM, Brian Meade (brmeade) <brmeade at cisco.com<mailto:brmeade at cisco.com>> wrote:
Ed,

It will probably be much easier for use to follow the call flow if you could send the actual SIP messaging for one of the calls.

Prack is really only used in response to a 180 Ringing with SDP or a 183 Session Progress with SDP.  That’s where early media gets established.

Brian

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: Tuesday, October 15, 2013 8:19 AM
To: Cisco VOIP
Subject: [cisco-voip] question(s) about SIP early media

I'm trying to troubleshoot what I think is an early media problem on a SIP trunk between CUCM 8.6 and a video conferencing system (Vidyo). If the Vidyo system tries to dial long distance, it does not get the audio prompt for the authorization code, which comes in from our long distance carrier prior to the call being established.
Audio is OK for local calls once the call is established.

I don't have direct access to the vidyo side. so I took a few packet captures at the CUCM side to try and puzzle out what is going on.

Vidyo sends SDP info immediately in its Invite message, and CUCM begins to send back audio from the MTP right away. Does CUCM need to send a PRACK here, or is the Status 100 reply from CUCM sufficient?

CUCM also responds with it's own 183 session progress message back that includes it's own SDP info. I never see a PRACK back from Vidyo, nor do I get audio. Would this imply that vidyo is not participating in the early media?

For a local call, vidyo does eventually start sending me audio when the session is completely established.

On the CUCM side for the SIP trunk profile, I have Early Offer support for voice and video calls checked and SIP Rel1XX options set to send PRACK for all 1xx messages (tried both settings though)

I'm asking my internal customer that owns the vidyo system to contact vidyo tech support, but I figured I'd see if any of you SIP gurus had an opinion :)

--
Ed Leatherman



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