Team do not have SIP server setup as of now to test this issue from our end. Hence CCing @hta:Requesting to please help us in triage this issue.Hence adding TE-NeedsTriageHelp lable to this issue for further triage.


Thanks!

I've been trying to come up with ways to test this without a SIP server and a WSS gateway. I found out that I could do h264 only in appr.tc. This works and I think what I might be running into is this: 
https://webrtc-review.googlesource.com/c/src/+/47581. 

After doing another trace I saw that when the call to createAnswer was done the signaling state was already in have-remote-offer. On the h264 test in appr.tc the signaling state doesn't go to have-remote-offer until after the ice candidates were added.

My question is could my issue be that if createAnswer is called when the signalingstatechange is already in 'have-remote-offer' it comes back before the app is ready? From the two traces (which are attached) it seems like the appr.tc is doing a lot of stuff between the createAnswer and setLocalDescription. I don't see the same thing in the JsSIP trace.

Also if you guys need a test bed I believe we can setup a softphone and a sip server on our interop site. It might take me a couple of days to get the gateway up and function with the firewall but I will try to provide it if needed.

Deleted: jssip_create_answer.txt 716 bytes

jssip_create_answer.txt 716 bytes View Download

Deleted: appr.tc_createAnswer 1022 bytes

appr.tc_createAnswer 1022 bytes Download

hbos@: Please take a look or reassign.

(reduced) fiddle for easier repro: https://jsfiddle.net/wn7yhz6v/1/
Generating an answer with a codec 0 is not ok.

[1:17:0512/210242.803029:ERROR:webrtcvideoengine.cc(281)] Setting codecs without a video codec is invalid: {}
[1:16:0512/210242.803227:ERROR:peerconnection.cc(4847)] Failed to set local video description recv parameters. (INVALID_PARAMETER)
[1:16:0512/210242.803357:ERROR:peerconnection.cc(1973)] Failed to set local answer sdp: Failed to set local video description recv parameters.

hta@: this is probably a case for your magic profile-level-id decoder ring.

surprised this doesn't throw as in issue webrtc:4957

Can you take a look, hta?

All,

As some more information if I change one of my sip clients to use packetization-mode=1 the codec doesn't change to 0 and I get a valid rtpmap. Will this only work if the packetization is 1? There are a lot of legacy sip devices that don't really like using packetiztion mode.

Critical line from SDP (copied from the fiddle):

a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42801E

The 80 has the constraint_set0_flag set, which means this is baseline.
42 means Constrained baseline, which is consistent.
1E means level-idc = 3.0, which is capable of 720x480@30, but not much more according to https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

It's missing level-asymmetry-allowed, which means that it'll only accept a response with exactly the same level.

Reassigning to mflodman for reassigning to someone who's currently doing H.264.

Magnus,
Are you the right person to look at this?

cc Stefan

I'm not really doing H264, but I guess no one is.

42801E is actually Baseline profile and not Constrained Baseline profile and I guess this is where the problem comes from.

Can you conform to Constrained Baseline instead of Baseline and use that in your negotiation? I think then everything will work.

If not, can someone attach the SDP negotation so we can inspect it? I was not able to run the fiddle. Do I need to do something besides pressing Run?

If I put in level-asymmetry-allowed it still doesn't work only a packetization-mode seems to work. The odd thing is when chrome make the initial call I don't have packetization-mode set in my answer and everything seems fine. If packetization-mode is left out when I call chrome I get bad video parameters.

Is there any reason why packetization-mode is required? I thought I read somewhere that packetization-mode was preferred in webrtc but I didn't think it was required.

I see now that WebRTC treats different packetization-mode as different codecs. This is a relatively recent changes, see https://bugs.chromium.org/p/webrtc/issues/detail?id=8808 for more info.

If I try to set my packetization-mode to 0 it still doesn't work. 8808 makes sense if packetization-mode is required, which I'm not sure if it is.

According to the standard, omitting packetization mode should mean the same thing as setting it to zero.

That's why I'm wondering if the WebRTC inside chrome is only accepting 1.

+Taylor who might understand the bigger picture here.

It looks like that's the case. If I change Phillip's repro to offer packetization-mode=1 everything works.

I'm not very familiar with codec negotiation, so I'm not sure what specifically the fix should be here.

Does the other side need to offer packetization-mode=1 for H264 to work?

> That's why I'm wondering if the WebRTC inside chrome is only accepting 1.

Correct. If the SIP endpoint is actually using packetization mode 1, it should put that in the SDP. If it's using 0, then we need to fix  http://crbug.com/600254 ; the work has been done to support packetization mode 0, apparently, but it's not being negotiated in SDP yet.

From what I'm finding if a call comes in with packetization-mode 0 then the video codecs get all screwed up and the call fails. Is this the expected behaviour until 600254 is fixed?

What do you mean by "video codecs get all screwed up"? In M66 and above (where bugs.webrtc.org/8808 is fixed), I'd expect "a=fmtp:97 packetization-mode=0" to be interpreted the same as there being no packetization mode attribute at all (meaning, the H264 codec will not appear in the answer).

The video codec is partially there so the entire call drops. I put the traces up above. The video line is reported but the payload type is 0 and then the call fails. That's the whole point of this bug the createAnswer is okish except with that video codec partially there then the setLocalDescription fails because of the mangled video codec. I believe the 0 in the payload type is trying to disable the codec but in the world of sip I believe you set the codec to inactive which might need to be done here.

Am I not understanding how this is working correctly?

Having a 0 in there for the port is correct but the rtpmap is gone. I think that is causing the call to fail. We have too many legacy devices that support only packetization 0 and telling our customers you need different phones probably won't fly.

I'm looking into other options until  http://crbug.com/600254  can be fixed so falling back to audio only properly here in my case isn't too big a deal for us because we can't use this solution as is.

When  http://crbug.com/600254  makes it into the beta software I'll give it a try. I just saw this bug got fixed.

I just tried the canary build and it works. As long as the fix for  http://crbug.com/600254  is merged into the official release in my case it is working. This bug must be a duplicate of  http://crbug.com/600254 .

Great. Looks like the fix landed in M69 which is scheduled to release around the beginning of September.