Let me double check, I might have mixed things up !
BR/pj
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: den 15 november 2018 19:27
To: Sundbaum Per-Johan (Telenor Sverige AB);
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RTP with wrong payload
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
