On 11/15/18 12:02 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
G.722 was offered in the initial INVITE to PBX, but was not accepted by PBX, in
200OK from PBX there were only G.711A
SDP in INITIAL invite:
SDP PDU
v=0
o=BroadWorks 400693062 1 IN IP4 195.54.102.188
s=-
c=IN IP4 195.54.102.188
t=0 0
m=audio 15148 RTP/AVP 8 110 111 0 96
b=AS:141
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:97 AMR/8000
a=fmtp:97
mode-set=0,2,4,7;mode-change-period=2;mode-change-capability=2;mode-change-neighbor=1;max-red=0
a=rtpmap:110 AMR/8000
a=fmtp:110 mode-change-period=2; mode-change-capability=2;
mode-change-neighbor=1; max-red=0
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=maxptime:20
a=ptime:20
The above seems a bit odd:
- why is there no rtpmap for 111?
- why is there an rtpmap for 97 that isn't mentioned in the m-line?
And then, the problem you are reporting is that the *offerer* is
receiving (on port 15148) packets with pt=9?
Thanks,
Paul
SDP in 200OK for INVITE from PBX
SDP PDU
v=0
o=- 6613665318425236764 2 IN IP4 172.18.8.21
s=MX-ONE
c=IN IP4 172.18.8.32
t=0 0
m=audio 30838 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sqn:0
a=cdsc:1 image udptl t38
a=cpar:a=T38FaxVersion:0
a=cpar:a=T38MaxBitRate:14400
a=cpar:a=T38FaxRateManagement:transferredTCF
a=cpar:a=T38FaxMaxBuffer:9772
a=cpar:a=T38FaxMaxDatagram:1472
a=cpar:a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv
BR/pj
-----Original Message-----
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul
Kyzivat
Sent: den 15 november 2018 17:37
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RTP with wrong payload
On 11/15/18 1:21 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
I should have given more details, in the example I gave there was actual a
couple of G.722 packets that was marked with payload type G.722 received in a
session where G.711A(PCMA/8000) was established as the agreed codec, the
receiving PBX did not have support for G.722.
As I interpret RFC 3550 the PBX should drop the G.722 packets and let the
session continue, and same applies also in case where G.722 is supported by
PBX, am I wrong ?
Just to be sure...
Are you saying that G.722 was not negotiated at all? Or that it wasn't the
first codec in the list?
If multiple codecs are negotiated, then it is permissible to use them, and even
mix their use. (This is most often a cobmination of telephone-events with
another codec, but isn't limited to that.
Can you post the actual offer/answer SDP that was used to negotiate the session?
Thanks,
Paul
BR/pj
-----Original Message-----
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Dale R. Worley
Sent: den 15 november 2018 05:10
To: Paul Heitkemper
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RTP with wrong payload
Paul Heitkemper <pheitkem...@iedaudio.com> writes:
RFC 3550 Section 5.1
" A receiver MUST ignore packets with payload types that it does not
understand."
Though this rule is based on the payload type code, and not the encoding. The
original post says only that the packets contain G.722 data, but if that data
is marked with the payload type code that was negotiated for G.711A, the
recipient will try to decode it as G.711A.
Perhaps the recipient can determine that the data is invalid (as G.711A) and
discard it, but more likely it will decode it into some sort of noise which it
will present to the user.
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
