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:[email protected]]
BR/pj
-----Original Message-----
From: Paul Kyzivat [mailto:[email protected]]
Sent: den 15 november 2018 19:27
To: Sundbaum Per-Johan (Telenor Sverige AB);
[email protected]
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:
> [email protected]<mailto:[email protected]>
> [mailto:[email protected]] On Behalf Of
> Paul Kyzivat
> Sent: den 15 november 2018 17:37
> To:
> [email protected]<mailto:[email protected]>
> 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:
>> [email protected]<mailto:[email protected]>
>> [mailto:[email protected]] On Behalf Of
>> Dale R. Worley
>> Sent: den 15 november 2018 05:10
>> To: Paul Heitkemper
>> Cc:
>> [email protected]<mailto:[email protected]>
>> Subject: Re: [Sip-implementors] RTP with wrong payload
>>
>> Paul Heitkemper <[email protected]<mailto:[email protected]>>
>> 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
>> [email protected]<mailto:[email protected]>
>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]<mailto:[email protected]>
>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]<mailto:[email protected]>
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
Message #1
------------------------------------------------------
IP
------------------------------------------------------
Source IP address = 195.54.102.102
Destination IP address = 10.12.11.32
------------------------------------------------------
UDP
------------------------------------------------------
Source port = 5060
Destination port = 5060
------------------------------------------------------
SIP
------------------------------------------------------
Request Line
INVITE sip:[email protected]:5060 SIP/2.0
Headers
Via: SIP/2.0/UDP 195.54.102.102:5060;branch=z9hG4bK3nr5k930387j6fobiun0.1
To: ". ."<sip:[email protected]>;cscf
From:
"+4670713753"<sip:[email protected]:37978;user=phone>;tag=1574694631-1542267460534-
Call-ID: [email protected]
CSeq: 187100636 INVITE
Max-Forwards: 68
Content-Length: 508
Contact: <sip:195.54.102.102:5060;transport=udp>
Content-Type: application/sdp
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, NOTIFY,
UPDATE
Accept: application/btbc-session-info
Accept: application/media_control+xml
Accept: application/sdp
Accept: application/x-hotsip-filetransfer+xml
Accept: multipart/mixed
Supported: timer
Privacy: none
Min-SE: 120
Session-Expires: 1800
Recv-Info: x-broadworks-client-session-info
Route: <sip:10.12.11.32:5060;lr>
Body
SDP PDU
v=0
o=BroadWorks 693770312 1 IN IP4 195.54.102.102
s=-
c=IN IP4 195.54.102.102
t=0 0
m=audio 12002 RTP/AVP 8 110 111 0 96
b=AS:141
a=rtpmap:8 PCMA/8000
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:111 AMR/8000
a=fmtp:111 octet-align=1; 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
Message #2
------------------------------------------------------
IP
------------------------------------------------------
Source IP address = 10.12.11.32
Destination IP address = 195.54.102.102
------------------------------------------------------
UDP
------------------------------------------------------
Source port = 5060
Destination port = 5060
------------------------------------------------------
SIP
------------------------------------------------------
Status Line
SIP/2.0 100 Trying
Headers
Via: SIP/2.0/UDP
195.54.102.102:5060;rport=5060;received=195.54.102.102;branch=z9hG4bK3nr5k930387j6fobiun0.1
Call-ID: [email protected]
From: "+4670713753"
<sip:[email protected];user=phone>;tag=1574694631-1542267460534-
To: ". ." <sip:[email protected]>;cscf
CSeq: 187100636 INVITE
Content-Length: 0
Message #3
------------------------------------------------------
IP
Source IP address = 10.12.11.32
Destination IP address = 195.54.102.102
------------------------------------------------------
UDP
------------------------------------------------------
Source port = 5060
Destination port = 5060
Length Field = 893
Checksum = 32cd'H
------------------------------------------------------
SIP
------------------------------------------------------
Status Line
SIP/2.0 183 Session Progress
Headers
Via: SIP/2.0/UDP
195.54.102.102:5060;rport=5060;received=195.54.102.102;branch=z9hG4bK3nr5k930387j6fobiun0.1
Call-ID: [email protected]
From: "+4670713753"
<sip:[email protected];user=phone>;tag=1574694631-1542267460534-
To: ". ."
<sip:[email protected]>;tag=ce2341f5-aa0b-41ed-ac17-051485521bfd;cscf
CSeq: 187100636 INVITE
Contact: <sip:10.13.11.32:5060>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL,
UPDATE, REGISTER, MESSAGE, REFER
Content-Type: application/sdp
Content-Length: 248
Body
SDP PDU
v=0
o=- 693770312 3 IN IP4 10.13.11.32
s=Asterisk
c=IN IP4 10.13.11.32
t=0 0
m=audio 14234 RTP/AVP 8 0 96
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
Message #4
------------------------------------------------------
IP
------------------------------------------------------
Source IP address = 10.13.11.32
Destination IP address = 195.54.102.102
------------------------------------------------------
UDP
------------------------------------------------------
Source port = 5060
Destination port = 5060
------------------------------------------------------
SIP
------------------------------------------------------
Status Line
SIP/2.0 183 Session Progress
Headers
Via: SIP/2.0/UDP
195.54.102.102:5060;rport=5060;received=195.54.102.102;branch=z9hG4bK3nr5k930387j6fobiun0.1
Call-ID: [email protected]
From: "+4670713753"
<sip:[email protected];user=phone>;tag=1574694631-1542267460534-
To: ". ."
<sip:[email protected]>;tag=ce2341f5-aa0b-41ed-ac17-051485521bfd;cscf
CSeq: 187100636 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL,
UPDATE, REGISTER, MESSAGE, REFER
Contact: <sip:10.13.11.32:5060>
Content-Type: application/sdp
Content-Length: 248
Body
SDP PDU
v=0
o=- 693770312 3 IN IP4 10.13.11.32
s=Asterisk
c=IN IP4 10.13.11.32
t=0 0
m=audio 14234 RTP/AVP 8 0 96
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
Message #5
------------------------------------------------------
IP
------------------------------------------------------
Source IP address = 10.13.11.32
Destination IP address = 195.54.102.102
------------------------------------------------------
UDP
------------------------------------------------------
Source port = 5060
Destination port = 5060
------------------------------------------------------
SIP
------------------------------------------------------
Status Line
SIP/2.0 603 Decline
Headers
Via: SIP/2.0/UDP
195.54.102.102:5060;rport=5060;received=195.54.102.102;branch=z9hG4bK3nr5k930387j6fobiun0.1
Call-ID: [email protected]
From: "+4670713753"
<sip:[email protected];user=phone>;tag=1574694631-1542267460534-
To: ". ."
<sip:[email protected]>;tag=ce2341f5-aa0b-41ed-ac17-051485521bfd;cscf
CSeq: 187100636 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL,
UPDATE, REGISTER, MESSAGE, REFER
Reason: Q.850;cause=16
Content-Length: 0
Message #6
------------------------------------------------------
IP
Source IP address = 195.54.102.102
Destination IP address = 10.13.11.32
------------------------------------------------------
UDP
------------------------------------------------------
Source port = 5060
Destination port = 5060
------------------------------------------------------
SIP
------------------------------------------------------
Request Line
ACK sip:[email protected]:5060 SIP/2.0
Headers
Via: SIP/2.0/UDP 195.54.102.102:5060;branch=z9hG4bK3nr5k930387j6fobiun0.1
CSeq: 187100636 ACK
To: ".
."<sip:[email protected]>;cscf;tag=ce2341f5-aa0b-41ed-ac17-051485521bfd
From:
"+4670713753"<sip:[email protected]:37978;user=phone>;tag=1574694631-1542267460534-
Call-ID: [email protected]
Max-Forwards: 68
Route: <sip:10.13.11.32:5060;lr>
Content-Length: 0
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
