No video SIP re-invite request to Asterisk over SIP Trunk

[collinks2]

Hello Everyone

I set up a sip trunk between Asterisk and CUCM . Asterisk endpoint calls CUCM endpoint .video and Audio work well. CUCM calls Asterisk endpoints ,video and Audio work .

Issues 

1)Asterisk endpoint calls CUCM endpoint, CUCM endpoint picks,places the call on hold and resumes the call, there will be no video. If Asterisk endpoint calls and places the  call on hold,then resumes, There will be video 

2). Asterisk endpoint calls CUCM cti route point ,7100 which triggers uccx application , video will be disabled. Normally when an endpoint calls CUCM cti route point, cti route point will send only audio since it is not a physical device but when the Agent (behind the IVR ) picks the call, there will be video.  In Asterisk , the endpoint sees no video because CUCM didn't send  video during the initial call. So when the Agent has picked the call,there will be no video. CUCM is supposed to include video in the sip re-invite to Asterisk over sip trunk. Audio works. If I manually turn the video on CUCM endpoint ,there will be video. This will be true because CUCM has sent new video stream 

I have played around with some settings in CUCM sip trunk and sip profile but no success . MTP is not checked . Pls can someone assist ?

[Jonathan Schulenberg]

Are you able to grab SIP traces of that trunk for the working and non-working scenarios? We need to see the SDP offer/answer, specifically who isn’t offering video.

[Stefan Mihajlov]

@collinks2 

This behavior comes from how CUCM handles video in mid-call re-INVITEs when the far end (Asterisk) didn’t advertise video initially. When the CUCM side places a call on hold or a CTI route point answers, CUCM sends a re-INVITE with only audio, and it won’t automatically add video again unless the far end had video in the original SDP.

To fix it:

• On the SIP trunk toward Asterisk, enable “Allow Video Capability in Early Offer” and “MTP Preferred Originating Codec” = None in the SIP Profile.

• Under the trunk’s Media Termination Point Required, keep it unchecked, but make sure “Accept Audio and Video” is enabled in the Trunk’s media settings.

• If Asterisk supports it, force it to always advertise video (send m=video lines) in the 200 OK, even for CTI or hold/resume cases.

Essentially, CUCM needs video in the initial SDP from Asterisk to include it again in a re-INVITE; otherwise, it will stay audio-only.

Best regards,
Stefan Mihajlov

Mark this post as Helpful if it helped you, and Accept as Solution if it resolved your question.

[collinks2]

@Jonathan Schulenberg ,I downloaded CUCM RTMT to check the sip trace but it is showing loading page infinitely. see screenshot. Thanks

@Stefan Mihajlov , Asterisk is advertising video. I have even forced it to always advertise video. (I will still recheck it). When Asterisk initially  calls CTI route point , the sip trace from Asterisk shows it is sending the video (m= video) but CUCM replies with M= video 0 and a= inactive ). As a result Asterisk disables it's video. When I am testing the call from Asterisk , I can view myself which means video is on, immediately cti route point picks it,  the video from Asterisk is disabled.I will try the options you mentioned and revert. I have not seen this "Accept Audio and Video"under Trunk's media settings. Media Termination is always unchecked."MTP Preferred Originating Codec”. I only see this under sip trunk and it is greyed out. It is only  enabled when MTP is checked .I have not seen it under sip profile. I have not seen this feature: "Allow Video Compatibility in the early offer" under sip trunk or sip  profile. see screenshots. Thanks for your wonderful contribution 

[Jonathan Schulenberg]

You can use Cloud-Connected UC to deploy WebRTMT as part of the Operations Dashboard service and avoid the local RTMT & Java mess entirely. You can also collect logs via SSH. In this case, SIP dialog should be identical between CUCM & Asterisk though, if it's easier to get from the other side.

@Stefan Mihajlov just copy/pasted an AI-generated answer. I wouldn't waste too much time chasing that.

The last screenshot from the CUCM SIP Trunk has a problem though: change DTMF Signaling Method from "OOB and RFC2833" to "No Preference." That choice is forcing CUCM to always ensure both DTMF methods are supported which is not what you want. CTI devices don't support RFC2833 for example, so CUCM would have to pull an MTP into the call - which almost never supports video - to make that work.

[collinks2]

@Jonathan Schulenberg  i used wire shark  to capture sip flows but i didn't see the agent phone in the trace.I don't know if it is because the Agent phone is another pc while wire shark is installed on a different pc

[Jonathan Schulenberg]

I need the actual PCAP (or equivalent text logs) so I can see the full SIP dialog with the exact call scenario that capture/log represents described and the relevant IPs of whatever is involved in the call - CUCM, Asterisk, IP Phone, CCX, etc. - annotated. I'm not going to guess from a screenshot.

If the Wireshark is of the SIP trunk between CUCM and Asterisk the only place you'll see the IP Phone's address is in the SDP body. CUCM is a SIP B2BUA so the trunk-side dialog will have very little mention of the line-side device.

[collinks2]

sorry for that,here is the attached pcap in a text file