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 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
