Hi again !
I just realized that I didn't answer your question
"It looks like there is an attempt to match on PT 108 with AMR/8000. But the
codec parameters don't match. Is the expectation that they will be matched by
PT and then will attempt to interwork the differing codec parameters?"
I'm not sure, but I will dig some more on the issue !
BR/pj
Sensitivity: Internal
-----Original Message-----
From: Paul Kyzivat <pkyzi...@alum.mit.edu>
Sent: den 22 januari 2021 23:44
To: Sundbaum Per-Johan (Telenor Sverige AB) <per-johan.sundb...@telenor.se>;
Ranjit Avasarala <ranjitka...@gmail.com>; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] reuse of payload type
On 1/22/21 12:34 PM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
> Hi !
> My tool is exporting the trace as requested, but it seems the resulting .pcap
> is not decoded so that one is not to any use.
> I have attached a HTML-version that I hope is at least a little better than
> my text.
That was fine.
Now to analyze this trace...
Note that IIUC the matching between offer and answer is done by codec name
(from rtpmap) and codec parameters (from fmtp. IIUC the individual parameters
in the fmtp need to be matched. The order that they are written is irrelevant.)
(Not by payload type, which can differ on the two ends, though people like it
better when it doesn't. But in this case it turns out that the PTs do all match
between a given offer and answer.)
In the first O/A, there is a match between PT 108 on both ends (AMR/8000,
max-red=0;mode-change-capability=2;mode-change-neighbor=1;mode-change-period=2;mode-set=7).
I imagine PT 116 in the answer is intended to match 116 in the offer.
But it technically doesn't because they don't have matching fmpt values.
I'm guessing it was treated as a match.
In the 2nd O/A, treating it independently of the first one, there are matches
on 100, 102, 104, 105, 109.
Then question you are asking is about the compatibility of Answer#2 and
Offer#1. The only match I find is for telephone-event between PT 116 in the
first answer and PT 100 in the second offer. I think that is what you were
concerned about. IMO *that* is conforming, since the phone uses
116 in both its first answer and its subsequent offer.
It looks like there is an attempt to match on PT 108 with AMR/8000. But the
codec parameters don't match. Is the expectation that they will be matched by
PT and then will attempt to interwork the differing codec parameters? I don't
think that is how it is supposed to work. But this isn't really my area - I
know the signaling but not the codec manipulation.
I find the following violations where a UA uses a PT for different
codec/parameters between the first and 2nd Invites:
pCSCF: 100, 102, 108
phone: 108
Thanks,
Paul
> [cid:image001.png@01D6F0ED.27F177E0]
>
> BR/pj
>
> From: Ranjit Avasarala <ranjitka...@gmail.com>
> Sent: den 22 januari 2021 18:02
> To: Sundbaum Per-Johan (Telenor Sverige AB)
> <per-johan.sundb...@telenor.se>
> Subject: Re: [Sip-implementors] reuse of payload type
>
> Hi Sundhaum
>
> either A or B should change in order to make a successful call or make use of
> codec conversion. instead of pasting the call flows, it will be better if u
> could attach the pcap file.
>
> On Fri, Jan 22, 2021 at 10:02 AM Sundbaum Per-Johan (Telenor Sverige AB)
> <per-johan.sundb...@telenor.se<mailto:per-johan.sundb...@telenor.se>> wrote:
> Much appreciated, thanks !
>
> I have added some more info.
>
>
>
> pCSCF --------- VoLTE-phone
>
> INVITE ->
>
> With SDP offer
>
> <- 180 Ringing
>
> <- 200OK with SDP answer
>
> ACK ->
>
> re-INVITE ->
>
> without SDP
>
> <- 200OK with SDP Offer
>
> ACK ->
>
> With SDP answer
>
>
>
>
>
> SDP in initial INVITE
> SDP PDU
> v=0
> o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
> s=-
> c=IN IP6 2a02:1400:10:1::4
> t=0 0
> m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
> b=AS:141
> a=rtpmap:108 AMR/8000
> a=fmtp:108 mode-set=7; mode-change-period=2;
> mode-change-capability=2; mode-change-neighbor=1; max-red=0
> a=rtpmap:102 AMR/8000
> a=fmtp:102 mode-set=7; max-red=0
> a=rtpmap:8 PCMA/8000
> a=rtpmap:100 AMR/8000
> a=fmtp:100 mode-change-period=2; mode-change-capability=2;
> mode-change-neighbor=1; max-red=0
> a=rtpmap:96 AMR/8000
> a=fmtp:96 max-red=0
> a=rtpmap:0 PCMU/8000
> a=rtpmap:116 telephone-event/8000
> a=ptime:20
> a=maxptime:20
> a=rtpmap:111 telephone-event/16000
>
> SDP in 200OK from VoLTE-phone with SDP as answer on initial INVITE
>
> o=sip:+46708xxx...@ims.mnc008.mcc240.3gppnetwork.org<mailto:sip%3a%2b46708xxx...@ims.mnc008.mcc240.3gppnetwork.org>
> 1611316978 0 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
> s=-
> c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
> t=0 0
> a=sendrecv
> m=audio 49120 RTP/AVP 108 116
> b=AS:37
> b=RS:462
> b=RR:1387
> a=rtpmap:108 AMR/8000
> a=fmtp:108 mode-set=7; max-red=0; mode-change-capability=2;
> mode-change-period=2; mode-change-neighbor=1
> a=rtpmap:116 telephone-event/8000
> a=fmtp:116 0-15
> a=ptime:20
> a=maxptime:20
> a=sendrecv
>
>
> SDP in 200OK from VoLTE-phone with SDP offer as answer on INVITE without SDP
> SDP PDU
> v=0
>
> o=sip:+46708xxxx...@ims.mnc008.mcc240.3gppnetwork.org<mailto:sip%3a%2b46708xxxx...@ims.mnc008.mcc240.3gppnetwork.org>
> 1611316978 1 IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
> s=-
> c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
> t=0 0
> a=sendrecv
> m=audio 49120 RTP/AVP 109 104 110 102 108 105 100
> b=AS:50
> b=RS:625
> b=RR:1875
> a=rtpmap:109 EVS/16000
> a=fmtp:109 br=13.2-24.4; bw=nb-wb; max-red=0; cmr=-1; ch-aw-recv=-1
> a=rtpmap:104 AMR-WB/16000
> a=fmtp:104 max-red=220; mode-change-capability=2
> a=rtpmap:110 AMR-WB/16000
> a=fmtp:110 octet-align=1; max-red=220; mode-change-capability=2
> a=rtpmap:102 AMR/8000
> a=fmtp:102 max-red=220; mode-change-capability=2
> a=rtpmap:108 AMR/8000
> a=fmtp:108 octet-align=1; max-red=220; mode-change-capability=2
> a=rtpmap:105 telephone-event/16000
> a=fmtp:105 0-15
> a=rtpmap:100 telephone-event/8000
> a=fmtp:100 0-15
> a=ptime:20
> a=maxptime:20
> a=sendrecv
>
>
> ACK with SDP as answer on offer from VoLTE-phone
>
> SDP PDU
>
> v=0
>
> o=- 805658488335263 1704590317 IN IP6 2A02:1400:10:1C::4
>
> s=-
>
> c=IN IP6 2a02:1400:10:1::4
>
> t=0 0
>
> m=audio 5394 RTP/AVP 104 105
>
> b=AS:54
>
> a=rtpmap:104 AMR-WB/16000
>
> a=fmtp:104 mode-set=0,1,2; mode-change-period=2;
> mode-change-capability=2; mode-change-neighbor=1; max-red=0
>
> a=rtpmap:105 telephone-event/16000
>
> a=ptime:20
>
> a=maxptime:40
>
> BR/pj
>
>
>
>
>
>
>
> -----Original Message-----
> From: Paul Kyzivat
> <pkyzi...@alum.mit.edu<mailto:pkyzi...@alum.mit.edu>>
> Sent: den 22 januari 2021 16:31
> To: Sundbaum Per-Johan (Telenor Sverige AB)
> <per-johan.sundb...@telenor.se<mailto:per-johan.sundb...@telenor.se>>;
> sip-implementors@lists.cs.columbia.edu<mailto:sip-implementors@lists.c
> s.columbia.edu>
> Subject: Re: [Sip-implementors] reuse of payload type
>
>
>
> On 1/22/21 7:55 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
>
>
>
> [snip]
>
>
>
>> As you can see the offer in initial INVITE have payload type 100:
>
>> a=rtpmap:100 AMR/8000 The offer in 200OK also have payload-type 100,
>
>> but now it is: a=rtpmap:100 telephone-event/8000
>
>>
>
>> I believe that this is causing failure when B-side (VoLTE-phone) is
>
>> sending TelephoneEvent(DTMF) to A-side (UAC)
>
>>
>
>> Do you think A-side should adapt or maybe reject the offer in 200OK or do
>> something else ?
>
>>
>
>>
>
>> RFC3264 8.3.2
>
>> "However, in the case of RTP, the mapping from a particular
>> dynamic payload type
>
>> number to a particular codec within that media stream MUST NOT
>> change
>
>> for the duration of a session. For example, if A generates an
>> offer
>
>> with G.711 assigned to dynamic payload type number 46, payload
>> type
>
>> number 46 MUST refer to G.711 from that point forward in any
>> offers
>
>> or answers for that media stream within the session. "
>
>
>
> I compared the two SDPs and find that there aren't *any* codec+fmtp sets that
> match. So this is messed up. But you haven't provided enough information to
> fully decipher what is going on. We need to see the answer to the first
> invite. The restrictions of rfc3264 section 8.3.2 pertain to the PT values
> used by a particular endpoint. (It is permissible to use different PTs on the
> two ends.) But in this case there isn't anything that could be in that first
> answer that could render this second answer valid.
>
>
>
> Regarding whether the A-side should adapt or reject: this is an
> implementation decision. The specs don't specify behavior for non-conforming
> usage. Or course there is also the problem that you can't reject an answer.
> All you can do is try sending another offer, or else terminate the call.
>
>
>
> It isn't entirely clear what you could try in order to carry on while
> accepting this 2nd answer. You could start sending using one or more of the
> codecs in the answer, but it is unclear what you would expect to receive.
>
>
>
> Thanks,
>
> Paul
>
>
>
>
> Sensitivity: Internal
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu<mailto:Sip-implementors@lists.c
> s.columbia.edu>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=04%
> 7C01%7Cper-johan.sundbaum%40telenor.se%7Cd95ce931a3a5498a19e308d8bf274
> 1ca%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637469522616658293%7C
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C1000&sdata=K0Bs6Zai%2BkP0QOeMdSEsAY2JR61eubBV
> W%2FKzJjJsiDo%3D&reserved=0<https://eur02.safelinks.protection.out
> look.com/?url=https%3A%2F%2Flists.cs.columbia.edu%2Fmailman%2Flistinfo
> %2Fsip-implementors&data=04%7C01%7Cper-johan.sundbaum%40telenor.se
> %7Cd95ce931a3a5498a19e308d8bf2741ca%7C1676489c5c7246b7ba639ab90c4aad44
> %7C1%7C0%7C637469522616668291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qz
> Ul0VtrMk1okldhHFHD5Ed9SooRSBm5pHJ3EFR5lTQ%3D&reserved=0>
>
>
> Sensitivity: Internal
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=04%
> 7C01%7Cper-johan.sundbaum%40telenor.se%7Cd95ce931a3a5498a19e308d8bf274
> 1ca%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637469522616668291%7C
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C1000&sdata=QzUl0VtrMk1okldhHFHD5Ed9SooRSBm5pH
> J3EFR5lTQ%3D&reserved=0
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
