How to disable Asterisk rewrite the code payload type in SDP

Asterisk Asterisk Support
1

We are installed the Asterisk 10.5.0 - rc1， when we make the call, the caller send the INVITE, in the SDP, the H.264 codec payload type is 125, but the callee received this INVITE from asterisk, the H.264 codec payload type is changed to 99, why? How to config the asterisk to disable this payload type rewrite ?

The caller sent INVITE:

INVITE sip:30050075@113.247.73.216 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.228:5204;branch=z9hG4bK-d8754z-9b2e047a2b4cd13a-1—d8754z-;rport
Max-Forwards: 70
Contact: sip:30052253@192.168.1.228:5204
To: sip:30050075@113.247.73.216
From: "30052253"sip:30052253@113.247.73.216;tag=5b5fb247
Call-ID: NjMzZDIwN2JlODFmNDc1MTQ4MjE4MTU2ZGFiODhlMWQ.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, REGISTER, SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: XTEM PHONE
Content-Length: 415

v=0
o=- 41436777 41436777 IN IP4 113.247.73.216
s=call
c=IN IP4 113.247.73.216
t=0 0
m=audio 21162 RTP/AVP 18 8 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 41976 RTP/AVP 125
a=rtpmap:125 H264/90000
a=fmtp:125 profile-level-id=42801E;packetization-mode=1
a=sendrecv

The callee received the INVITE:

INVITE sip:30050075@113.247.73.216:6072;rinstance=2a0c99bdf61cd64c SIP/2.0
Via: SIP/2.0/UDP 93.191.108.26:5060;branch=z9hG4bK5a903584;rport
Max-Forwards: 70
From: “30052253” sip:30052253@93.191.108.26;tag=as4b3a1fa3
To: sip:30050075@113.247.73.216:6072;rinstance=2a0c99bdf61cd64c
Contact: sip:30052253@93.191.108.26:5060
Call-ID: 46c6e82f136557c53d148ed928182aaa@93.191.108.26:5060
CSeq: 102 INVITE
User-Agent: CoCoS
Date: Wed, 23 May 2012 11:08:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces
Remote-Party-ID: “30052253” sip:30052253@93.191.108.26;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 401

v=0
o=root 119988351 119988351 IN IP4 93.191.108.26
s=Asterisk PBX 10.2.1
c=IN IP4 93.191.108.26
b=CT:384
t=0 0
m=audio 11280 RTP/AVP 18 3 0 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
m=video 10532 RTP/AVP 99
a=rtpmap:99 H264/90000
a=sendrecv

2

You can’t and there is no need to. What matters is that the number references an rtpmap line specifying H264/9000.

The incoming channel uses the number to lookup the rtpmap entry, and uses the contents of that to set its internal codec number. The outgoing channel then chooses a number (that might be internal one) and identifies what it means with an appropriate rtpmap line.

If you are dealing with a broken device that cannot handle this, you need to identify that device here.

(Actually, you could probably change the source code, so that it uses 125 on the outgoing side (note literal 125, not a copy of what was used on the incoming side.)

3

I’m having the same issue. I am connecting a LifeSize Softphone. Asterisk is doing a reinvite with a different payload and the softphone can not decode the video. If I change the RTP packets to be the original payload type number, the LS Softphone can decode them fine.

RFC 3264 indicates that the payload type is not just a map in the SDP:
For recvonly RTP streams, the payload type numbers indicate the value
of the payload type field in RTP packets the offerer is expecting to
receive for that codec. For sendonly RTP streams, the payload type
numbers indicate the value of the payload type field in RTP packets
the offerer is planning to send for that codec. For sendrecv RTP
streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send.
However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.

I think the re-invite should pass on the original expected payload type.

. Scoops

4

If Asterisk is doing anything other than native bridging, Asterisk will change the type numbers in the RTP, in the same way as it changes them in the SDP.

If it is doing native bridging, but not either passing through the SDP codec numbers or modifying those in the RTP, you need to raise a bug report. You will need to include protocol tracing showing the SDP and the RTP, and level debug output for chan_sip.c.

Note that the fix might be to disable native bridging in this case.

5

issues.asterisk.org/jira/browse/ASTERISK-17410 seems to be relevant.

6

This looks like the same issue.
What should be my next move? Should I open a new bug report?
I could fix it myself, but I am not familiar with the Asterisk code. Can someone point to where in the code this could be fixed?

7

The appropriate bug reporting action would be to add a comment to the existing bug report. Me too’s and offers to test candidate fixes tend to increase priority of fixes. This one will affect so few people that the real priority will be quite low.

The relevant code will be in chan_sip.c, as that is the only place that has access to the raw SDP and can do native bridging. I would suggest that, if you are not familiar with Asterisk internal, you wait for someone who is to take an interest in the problem, and simply offer, on the existing bug report, to act as a tester.

Although I haven’t looked, I doubt that the problem is a minor omission. I suspect it goes to the heart of the SDP processing, which is quite complicate, has been subject to some major rework, and even now I suspect is not as general as it should be.

I suppose there might be a way of making it work for you, without providing a general solution.

8

It would appear that the underlying problem was first reported in 2004, but someone, not far from here, closed it, as fixed, when they meant to suspend it.

issues.asterisk.org/jira/i#browse/ASTERISK-1755