Re: [Sip-implementors] RTP with wrong payload
I couldn't find all the details for my previous example, but I did find a similar case where there are a couple of AMR packets sent to PBX that makes the PBX decline the call. I have attached the signaling somewhat anonymized. Call flow [cid:image001.png@01D47D1D.5DBD2EF0] 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> > [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<mailto: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> >> [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<mailto:sip-implementors@lists.cs.columbia.edu> >> Subject: Re: [Sip-implementors] RTP with wrong payload >> >> Paul Heitkemper mailto: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
Re: [Sip-implementors] RTP with wrong payload
> > > 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 > G.722, PT 9 is not even mentioned in the m-line, therefore not relevant. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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 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
Re: [Sip-implementors] RTP with wrong payload
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 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
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 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
Re: [Sip-implementors] RTP with wrong payload
Thank you very much Alex, Dale and Paul ! BR/pj -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Alex Balashov Sent: den 15 november 2018 07:20 To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] RTP with wrong payload Correct -- if the party receiving the G.722 packets did not advertise support for the G.722 payload type in its SDP stanza, it should just ignore them if they arrive anyway. On Thu, Nov 15, 2018 at 06:21:14AM +, 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 ? > 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 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 -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ 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
Re: [Sip-implementors] RTP with wrong payload
Correct -- if the party receiving the G.722 packets did not advertise support for the G.722 payload type in its SDP stanza, it should just ignore them if they arrive anyway. On Thu, Nov 15, 2018 at 06:21:14AM +, 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 ? > 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 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 -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RTP with wrong payload
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 ? 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 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
Re: [Sip-implementors] RTP with wrong payload
Paul Heitkemper 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
Re: [Sip-implementors] RTP with wrong payload
Thank you very much Paul ! BR/pj -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Heitkemper Sent: den 14 november 2018 16:35 To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] RTP with wrong payload RFC 3550 Section 5.1 " A receiver MUST ignore packets with payload types that it does not understand." -- Paul On 2018-11-14 01:30, Sundbaum Per-Johan (Telenor Sverige AB) wrote: > Thanks ! > Ok, but to be more specific, are there any general recommendations on > question like: Should the PBX drop the packets with wrong payload and let the > call/session continue or should the PBX also drop the entire call ? > BR/pj > > -Original Message- > From: Dale R. Worley [mailto:wor...@ariadne.com] > Sent: den 14 november 2018 05:25 > To: Sundbaum Per-Johan (Telenor Sverige AB) > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] RTP with wrong payload > > "Sundbaum Per-Johan (Telenor Sverige AB)" > writes: > >> Can someone help me getting a link to information regarding how a PBX should >> handle the case when for example the codec G.711A is agreed upon, but >> somehow there are a couple of G.722 packets received that have the same >> ports on UDP level, but clearly belongs to another RTP stream when you look >> at sequence numbers, timestamps and SSRC ? > > There's no real definition of "clearly belongs to". If a packet arrives at a > port, it is processed according to the usage that has been negotiated for > that port. > > Dale > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors [1] Links: -- [1] 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
Re: [Sip-implementors] RTP with wrong payload
RFC 3550 Section 5.1 " A receiver MUST ignore packets with payload types that it does not understand." -- Paul On 2018-11-14 01:30, Sundbaum Per-Johan (Telenor Sverige AB) wrote: > Thanks ! > Ok, but to be more specific, are there any general recommendations on > question like: Should the PBX drop the packets with wrong payload and let the > call/session continue or should the PBX also drop the entire call ? > BR/pj > > -Original Message- > From: Dale R. Worley [mailto:wor...@ariadne.com] > Sent: den 14 november 2018 05:25 > To: Sundbaum Per-Johan (Telenor Sverige AB) > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] RTP with wrong payload > > "Sundbaum Per-Johan (Telenor Sverige AB)" > writes: > >> Can someone help me getting a link to information regarding how a PBX should >> handle the case when for example the codec G.711A is agreed upon, but >> somehow there are a couple of G.722 packets received that have the same >> ports on UDP level, but clearly belongs to another RTP stream when you look >> at sequence numbers, timestamps and SSRC ? > > There's no real definition of "clearly belongs to". If a packet arrives at a > port, it is processed according to the usage that has been negotiated for > that port. > > Dale > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors [1] Links: -- [1] 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
Re: [Sip-implementors] RTP with wrong payload
Thanks ! Ok, but to be more specific, are there any general recommendations on question like: Should the PBX drop the packets with wrong payload and let the call/session continue or should the PBX also drop the entire call ? BR/pj -Original Message- From: Dale R. Worley [mailto:wor...@ariadne.com] Sent: den 14 november 2018 05:25 To: Sundbaum Per-Johan (Telenor Sverige AB) Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] RTP with wrong payload "Sundbaum Per-Johan (Telenor Sverige AB)" writes: > Can someone help me getting a link to information regarding how a PBX > should handle the case when for example the codec G.711A is agreed > upon, but somehow there are a couple of G.722 packets received that > have the same ports on UDP level, but clearly belongs to another RTP > stream when you look at sequence numbers, timestamps and SSRC ? There's no real definition of "clearly belongs to". If a packet arrives at a port, it is processed according to the usage that has been negotiated for that port. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RTP with wrong payload
"Sundbaum Per-Johan (Telenor Sverige AB)" writes: > Can someone help me getting a link to information regarding how a PBX > should handle the case when for example the codec G.711A is agreed > upon, but somehow there are a couple of G.722 packets received that > have the same ports on UDP level, but clearly belongs to another RTP > stream when you look at sequence numbers, timestamps and SSRC ? There's no real definition of "clearly belongs to". If a packet arrives at a port, it is processed according to the usage that has been negotiated for that port. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] RTP with wrong payload
Hi ! Can someone help me getting a link to information regarding how a PBX should handle the case when for example the codec G.711A is agreed upon, but somehow there are a couple of G.722 packets received that have the same ports on UDP level, but clearly belongs to another RTP stream when you look at sequence numbers, timestamps and SSRC ? Thanks ! BR/pj ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
