Lua Normalization Script - Changing max-fs in 200 OK

[Xisby]

I'm attempting to change the SDP media description attributes under video in the 200 OK outbound INVITE. 

example:

Under m=video

a=fmtp:97 profile-level-id=42801F;packetization-mode=0;max-mbps=244800;max-fs=8161;level-asymmetry-allowed=1

Wanting to change max-fs to 3600.  

Has anyone ever needed to do this?  I'm able to modify a lot of things within normalization but can't seem to modify just this value.  

[dstaudt]

From the docs, it seems you would use getSdp/setSdp for manipulation media, though it seems you would need to 'manually' manipulate the SDP payload via Lua primitives, perhaps:

M = {}
function M.outbound_INVITE(msg)
    local sdp = msg:getSdp()
    if sdp
        then
            sdp = sdp:gsub("max-fs=%d*", "max-fs=3600")
            msg:setSdp(sdp)
        end
    end
return M

 Lua pattern matching reference

[Xisby]

Thanks for this.  Unfortunately this didn't resolve as that script doesn't change the value.  Wild cards or, Magic Characters don't seem to have much of an affect in sdp manipulation.  This script simply doesn't do anything.

[dstaudt · Accepted solution]

Appears "-" is a reserved/magic character in Lua patterns, escaping seems to work in the Lua demo tool (I don't have an easy way to lab test:)

[Xisby]

Placing the % worked!  I'm able to manually change it to a static number. However, I've been now asked to match the attribute of the inbound.INVITE and apply it to the outbound_200_OK SDP.   This has been a challenge..  Thoughts?

[dstaudt]

It might be good to understand a bit more about what you're trying to accomplish and why.  If you are modifying the SDP on SIP packets going out from CUCM via Lua, I could see that being a problem, as CUCM will not recognize/understand that you have made that change on its behalf.  E.g., if you change max-fs=3600, the far-end will happily assume that is what CUCM intended to negotiate, but CUCM will set up its receiving device/MTP using what it thinks it negotiated, i.e. max-fs=8161.
I'm not an expert on trunking/H.323/gateways, but AFAIK CUCM handles media bandwidth/format negotiations via regions: https://ciscoshizzle.blogspot.com/2015/06/regions-and-locations-in-cucm-for-video.html.
Perhaps if you insert a CUBE tandem into the pathway, CUBE will have the capability to more finely control specific H.323 params like this (I'm not an expert on CUBE either..?)

[Xisby]

I'll explain better for sure.  We have a 3rd party platform that's utilized for our call center environment.  The recent update to this platform has caused video to stop working.  In working with this 3rd party platform they've identified the reason: Because the max-fs value that jabber is replying with (max-fs=8161) is causing their software to stop sending video.  They state it's because the value is too high, causing the platform to disable any attempts at a video call.  So, I can change this value manually and video is fine.  However, I'd like to prevent this problem from happening in future versions and would like to simply look at the INVITE coming from the platform, copy the max-fs value, and perform a media replacement of max-fs value in the 200_INVITE brought in from jabber. 

[dstaudt]

AFAIK what happens in the Lua script stays in the Lua script.  It is not possible to store or transmit state/data or read data anywhere but from the immediate SIP message.  As mentioned, I'm a bit nervous about faking media negotiation parameters as then it could be possible that video starts, but is corrupted/low-quality - all the time, or just in certain circumstances (e.g. screen sharing) - because the endpoints aren't aware of the manipulation and have assumptions about e.g. max-fs.
I'm not finding much on google re configuring low-level params like max-fs in Jabber/CUCM...have you contacted Cisco TAC for any advice?
Since the problem is occurring after an upgrade to the 3rd party system, can they offer any options to (at least) revert to the previous behaviour in this scenario?

[Xisby]

Thanks for your explanation and reply.  I agree to everything that you're saying and have previously voiced my concern about this.  I think the best idea is to remove this media description so the outgoing sdp accepts anything that our 3rd party platform is capable of doing.  I've tested this theory and it has worked 100% of the time.  I've also been able to remove the sdp from the initial INVITE and apply the sdp from the 200_INVITE reply but not able to 'cherry pick' just the max-fs media.  

This 3rd party system keeps us on our toes.  This seems to be an on-going issue in that we have to modify certain things to accommodate their hiccups. 

Either way, thank you greatly for your input and I'll mark your response as an acceptable solution, because it is!