Packetization-mode oddity

Asterisk Asterisk SIP
1

Hi

I have a Bria softphone that sends the follow INVITE for an outgoing call:

INVITE sip:101@192.168.1.190 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.142:62453;branch=z9hG4bK-524287-1---8f1eb1bcf3e7b152;rport
Max-Forwards: 70
Contact: <sip:102@192.168.1.142:62453;rinstance=c637c153d1d942f4>
To: <sip:101@192.168.1.190>
From: "102"<sip:102@192.168.1.190>;tag=67bac925
Call-ID: 104678NDg0Njc5MzEwZGM3MTFiYmU2M2Y0ZTllOTJlMjQ4NmY
CSeq: 1 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE
Content-Type: application/sdp
Supported: replaces
User-Agent: Bria 5 release 5.8.4 stamp 104678
Content-Length: 658

v=0
o=- 13247944920270962 1 IN IP4 192.168.1.142
s=Bria 5 release 5.8.4 stamp 104678
c=IN IP4 192.168.1.142
t=0 0
m=audio 57962 RTP/AVP 9 18 120 0 84 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:120 opus/48000/2
a=fmtp:120 useinbandfec=1; usedtx=1; maxaveragebitrate=64000
a=rtpmap:84 speex/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 63602 RTP/AVP 127 126 100
a=rtpmap:127 H264/90000
a=fmtp:127 profile-level-id=428016;packetization-mode=0
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=428016;packetization-mode=1
a=rtpmap:100 VP8/90000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=sendrecv

And Asterisk creates and sends the following INVITE message but it has picked the H264 option with packetization-mode=1 and my receiving softphone can’t support that mode so doesn’t support video at all for the call. Is there a way to get Asterisk to either add both options to the SDP or to say I only want packetization-mode=0?
I have no options in the Bria softphone btw to influence what it sends for an outgoing call.
Calls from my Baresip client are ok to Bria because the SDP only supports packetization-mode=0 so that’s the only choice.

INVITE sip:101-0x1a33890@192.168.1.162:52991 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.190:5060;branch=z9hG4bK600d42de
Max-Forwards: 70
From: "102" <sip:102@192.168.1.190>;tag=as0eb169d8
To: <sip:101-0x1a33890@192.168.1.162:52991>
Contact: <sip:102@192.168.1.190:5060>
Call-ID: 79db7dca2f9bee8e4317748d13d9eb42@192.168.1.190:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.18.3~dfsg-1ubuntu4
Date: Fri, 23 Oct 2020 16:42:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-Hangup-Allowed : false
Content-Type: application/sdp
Content-Length: 411

v=0
o=root 1100857615 1100857615 IN IP4 192.168.1.190
s=Asterisk PBX 13.18.3~dfsg-1ubuntu4
c=IN IP4 192.168.1.190
b=CT:384
t=0 0
m=audio 18198 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv
m=video 17790 RTP/AVP 126
a=rtpmap:126 H264/90000
a=fmtp:126 packetization-mode=1;profile-level-id=428016
a=sendrecv
2

Asterisk does not currently support multiple formats like that with different attributes.

3

Hi

Ok thanks for the reply, that’s interesting.

Is that legal SDP to have the same codec used but with different attributes?

Any suggestions to get around this? I could maybe modify my receiving softphone to ignore the packetization-mode attribute being set to 1 instead of 0 if it’s from a Bria client, but that sounds like a hack.

Regards.

Gary

4

It’s legal to have multiple with different attributes. I don’t really have any suggestions from an Asterisk perspective, the support just isn’t there for it.

5

I’m having this same issue with a video call to an external server I don’t control. Is there any way to force packetization-mode=0?

6

Maybe there’s a way we can request this feature go into a future release?

7

We don’t currently accept feature requests without patches on the issue tracker. You’d need someone with an interest in working on this, or to provide a bounty to potentially elicit someone to work on it.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.