Hi ! Just to be sure, with B-side you mean the VoLTE-phone ? BR/pj From: Ranjit Avasarala <ranjitka...@gmail.com> Sent: den 22 januari 2021 15:25 To: Sundbaum Per-Johan (Telenor Sverige AB) <per-johan.sundb...@telenor.se> Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] reuse of payload type
Hi Sundbaum Here the B side should adapt and change the common codec list to suit the one received. so change 100 to AMR/8000. Then the call will be successful. Regards Ranjit On Fri, Jan 22, 2021 at 6:56 AM Sundbaum Per-Johan (Telenor Sverige AB) <per-johan.sundb...@telenor.se<mailto:per-johan.sundb...@telenor.se>> wrote: Hi ! I have a call scenario where I would appreciate opinions on which side is most correct or perhaps least incorrect ! Call is from external operator, but the interesting part is between pCSCF and a VoLTE-phone. (the logs is from between pCSCF and the VoLTE-phone) pCSCF sends initial INVITE with sdp to UAS(VoLTE-phone) 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 later in same dialog an AS sends re-INVITE without SDP which results in 200OK answer from UAS(VoLTE-phone) with 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 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. " BR/pj Sensitivity: Internal _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu<mailto:Sip-implementors@lists.cs.columbia.edu> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cs.columbia.edu%2Fmailman%2Flistinfo%2Fsip-implementors&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7Cc29987664daa494844fe08d8bee18faa%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637469223282439333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TokAARSCmKKLtcL3uOTVJ0sz2bGWI83h6%2BDwQmZzwK8%3D&reserved=0> Sensitivity: Internal _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
