Can not transfer h264 Video throw Asterisk 13.11.2 PJSIP

GURUs! Help!!!

Can not transfer h264 Video throw Asterisk 13.11.2 PJSIP.

I have no idea and appreciate any kick…
Detailes below

Thank you in advance
Ilya

topology:
two Video sources
Aster UA (SipPhone on Win)
GOOD 192.168.0.220---->
PT=97
192.168.0.200 -----> 192.168.0.3
/
BAD 192.168.0.210—>
PT=98

!!! Call from source A is ok, but from B No video. !!!

The only difference I found is different Payoad Types (PT) of sources (mentioned above).
(sipsak and 127.0.0.1 loopback below is a sipproxy)

========= INVITE from GOOD:

INVITE sip:200@192.168.0.200 SIP/2.0
Via: SIP/2.0/TCP 127.0.0.1:4073;branch=z9hG4bK.329e5021
Max-Forwards: 70
From: sip:sipsak@127.0.0.1;tag=as21b1f2a7
To: sip:200@127.0.0.1
Contact:sip:sipsak@127.0.0.1:4073
Call-ID: 754308734
CSeq:1 INVITE
User-Agent: My PROXY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length:223

o=- 1 1 IN IP4 127.0.0.1
s=My H264 Session
c=IN IP4 127.0.0.1
m=audio 55000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 56000 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=420028;

========== INVITE from BAD:

INVITE sip:200@192.168.0.200 SIP/2.0
Via: SIP/2.0/TCP 127.0.0.1:4663;branch=z9hG4bK.329e5021
Max-Forwards: 70
From: sip:sipsak@127.0.0.1;tag=as21b1f2a7
To: sip:200@127.0.0.1
Contact:sip:sipsak@127.0.0.1:4663
Call-ID: 1952682238
CSeq:1 INVITE
User-Agent: My PROXY
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length:267

o=- 1 1 IN IP4 127.0.0.1
s=My H264 Session
c=IN IP4 127.0.0.1
m=audio 55000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 56000 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42001E; packetization-mode=1; sprop-parameter-sets=Z0IAHtoFB8Q=,aM4FChEg


RTP packets HEX dump

======================================== good call
192.168.0.220 —> 192.168.0.200 - source to Aster

0000 80 e1 c6 8a 04 17 d8 2a 3a 1b a1 46 78 00 15 67
| | payload ->
| PT =97

0010 42 00 1e e9 02 83 f5 c4 80 06 dd d0 00 cd fe 60
0020 0d 88 10 94 00 04 68 ce 31 52

192.168.0.200 —> 192.168.0.003 – Aster to dest

0000 78 00 15 67 42 00 1e e9 02 83 f5 c4 80 06 dd d0
0010 00 cd fe 60 0d 88 10 94 00 04 68 ce 31 52

========================================= no Video
192.168.0.210 —> 192.168.0.200 – source to aster

0000 80 62 00 00 00 00 20 00 0e 5c 24 98 7c 85 88 84
| | payload ->
| PT =98
0010 04 3f 93 df 01 81 b2 6e 24 00 04 23 79 fe 00 38

192.168.0.200 —> 192.168.0.003 — Aster to dest

0000 7c 85 88 84 04 3f 93 df 01 81 b2 6e 24 00 04 23
0010 79 fe 00 38 04 03 b9 22 4b 3e f7 be c2 2b a0 fa

Looks also like the bad one has a different supported profile-level-id and different sprop-parameters-sets too.

Perhaps it’s a set of parameters that aren’t supported by the other party.

You might check the logs of the decoding endpoint to see if it lends any insight into why it doesn’t like one versus the other. Asterisk should only being passing through what it gets from each endpoint.

Matthew Fredrickson

Thank you Mathew.

Seems I have logical missunderstanding of Aster RTP or media treatment.
You and other adault boys stress that Aster just “passing through what it gets from each endpoint.”

I do not understand how Aster can “just pass thread” from one side and change SDPs and RTP headers from other.

I have just dive into specifications and have impression that both - payload and SDP&RTPheader - attributes should correspond each other.

And what is practical solution of the problem - insert mediation transcoder (ffmpeg) to convert incoming format to “tested” one?
Or something more smart?

BR
Ilya

Asterisk converts the codec number to an internal codec number and puts the payload into internal, frame structures, possibly splitting an incoming packet into more than one frame. However, the payload is completely unchanged. At the outgoing side, it regenerates the correct codec number, and the timestamp and sequence information, and splits payloads if they would exceed the maximum size, but, again, for video, does not touch the actual media stream.

Asterisk doesn’t touch the payload of video. In fact, to do so would really require hardware assist of a type that you would normally get from a video card.

:unamused:
What is “codec number”?

When I order a table in IKEA I assume what i will be (=video) and packet in IKEA stile (=codec H264).
I know that there will be manual and on the first page there will be list of contents and the set of tools I need to assemble the table (= SDP attributes)
If table is very big and arrives in separate delivery there should be description how can I treat this delivery (=RTP headers).

Keeping correct info I can smoothly assemble table part by part after each delivery.
But if any documentation will be changed - I’ll fail.

It looks like Asterisk provides a chair description for my table?

SDP identifies the support streams by payload type. The SDP has a table of mappings between payload type and name of codec, plus any codec parameters.

The meida itself is transmitted using RTP which only has the payload type.

Asterisk is not fundamentally a SIP switch, so it is not bound to the payload types used by the SIP. It transfers the media between input and output using a codec type number, which is different from the payload type. In fact it is a bit map, as, whilst any one frame can only have one type, it communicates the allowable type between input and output using the same coding scheme.

The outgoing SIP channel agrees a payload type, using SDP, which may be different from the incoming one, although the name in the SDP should be the same, and, in any case, the outgoing side doesn’t in general, know the incoming one (unless there is a native bridge). Asterisk converts its internal codec number into the payload type agreed on the outgoing side. For audio, it may also transform the actual media contents to a codec understood by the outgoing side.

Generally, if you want very simple pass through, you do not use a back to back user agent PABX like Asterisk, you use a SIP proxy.

Asterisk is open source, so if you think you can implement it better (remembering that it has to handle SIP to analogue and SIP to other VoIP conversions, you are welcome to contribute tested source code, or fork your own version. However note that the translation from a codec name to a payload type is a choice made by the designers of SIP, not by the designers of Asterisk.

1 Like