How to prevent Janus from automatically responding 200 to SIP UPDATE messages?

General
1

Hello, I am using Janus as a SIP gateway for a web frontend and a mobile phone. I have encountered a problem with the SIP UPDATE messages sent by the mobile phone.

The scenario is as follows:

The web frontend sends a SIP INVITE message to the mobile phone through Janus.

The mobile phone responds with a SIP UPDATE message, which contains an SDP that specifies three video codecs that it supports.

Janus auto responds with a 200 OK message, which SDP contains the codec is the web frontend’s SDP first codec . The video codec is not one of the three codecs that the mobile phone supports.

The call is established, but the video from the web frontend cannot be decoded by the mobile phone.

I think this behavior is incorrect, because Janus should not respond to the SIP UPDATE message with an SDP that does not match the one offered by the mobile phone. Janus should handle the SIP UPDATE message in the same way as it handles the SIP re-INVITE message: either configure it to automatically re-INVITE, or forward it to the web frontend and let it update the SDP.

I tried to modify the janus_sip_sofia_callback function in the janus_sip.c, and added a case for nua_i_update event. I set a breakpoint there, and captured the packets. However, I found that when the breakpoint was triggered, Janus had already sent a 200 OK message to the mobile phone. I don’t know how to prevent Janus from automatically responding 200 to the SIP UPDATE message. I also set breakpoints at all the places where nua_respond function was called, but none of them was triggered when Janus sent the 200 OK message.

How can I make Janus handle the SIP UPDATE message properly? Is there any configuration option or code change that I need to do?

Thank you very much for your attention and assistance.

The following issue stores the sdp text during the call

issue

1 Like
2

I don’t think we support nua_i_update: as you noticed, we don’t have a case for it in the callbacks, which means it’s the Sofia SIP stack that automatically sends a 200 back on its own. That said, in general Janus doesn’t handle anything: codec negotiation is left to the browser, and the SIP plugin doesn’t interfere. In your case, it’s because the method is not explicitly supported, and it’s the library that’s interfering.

1 Like
3

I’ve just pushed a commit that removes UPDATE from the list of supported methods, when creating the SIP stack, since as a matter of fact we do not support it.

1 Like
4

as I notice above i am testing VoLTE calls and i find all i test case, has the UPDATE SDP message.

The mobile phone responds with a SIP UPDATE message, which contains an SDP that specifies three video codecs that it supports.

Will this operation cause the call to fail?

5

Actually, I want to know how to solve the interference of this library.
Do I need to submit an issue under the sofia-sip repository?

6

I don’t know, but for sure the library shouldn’t autoanswer with a 200. In theory this way it should autoanswer with an error that says the message is unsupported (not sure which). I’d expect your endpoint to know UPDATE is not supported, and switch to something else (maybe a re-INVITE).

7

image

i just try to remove UPDATE method like you commit and the call failed with 405

8

Yes, that’s what I’d expect to happen, since we don’t support it.

9

Invite: Linephone → VoLTE

m=video 56527 RTP/AVP 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801F

UPDATE SDP: VoLTE → Linephone

m=video 18994 RTP/AVP 114 113 118
c=IN IP4 59.26.223.115
a=rtpmap:114 H264/90000
a=fmtp:114 profile-level-id=42C01F;sprop-parameter-sets=Z0LAH9oC0ChoBtChNQ==,aM4G4g==;packetization-mode=1;sar-understood=16;sar-supported=1
a=rtpmap:113 H264/90000
a=fmtp:113 profile-level-id=42C01F;sprop-parameter-sets=Z0LAH9oC0ChoBtChNQ==,aM4G4g==;packetization-mode=0;sar-understood=16;sar-supported=1
a=rtpmap:118 H264/90000
a=sendrecv

200 OK: Linephone → VoLTE

m=video 56527 RTP/AVP 118
a=rtpmap:118 H264/90000
a=fmtp:118 profile-level-id=42801F; packetization-mode=1

Different UserAgent have different processing method. Linephone directly changes its PlayloadType to be the same as the first one of the VoLTE which is 118 when processing the Update SDP. Note that fmtp is consistent with the Invite. And it work.

But as you say

We just didn’t get a chance to handle it like Linephone did

10

Browsers won’t change the payload type, so any change in Janus or Sofia would be inconsequential.

11

A large number of tests (about 30 phones of different models and carriers) found that in most cases, the current mode to respond to Update messages (Sofia), also can be normal to build audio and video calls, but some phones have problems, must need to be consistent Playload Type. Therefore, I recommend not removing support for Update messages.

12

I know, I’m just saying, we didn’t have a chance to pass the Update to the browser before Sofia responded to the update message

13

I’m not removing it, it was never there :grin: I’m just making it explicit we don’t support it, otherwise as you said the risk is encountering broken and inconsistent sessions as you did.

1 Like
14

I solved this problem. After createOffer, I changed the payload of the first option of video encoding in sdp to 114
I found that the video decoding preference in the sdp sent by all mobile phones that cannot parse the video is 114

3 Likes