Thank you very much ! 😊 From: Ranjit Avasarala <ranjitka...@gmail.com> Sent: den 22 januari 2021 18:39 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 There is a codec mismatch between A and B - either of them have to change or a transcoder needs to be used Regards Ranjit On Fri, Jan 22, 2021 at 11:34 AM Sundbaum Per-Johan (Telenor Sverige AB) <per-johan.sundb...@telenor.se<mailto:per-johan.sundb...@telenor.se>> 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. [cid:image001.png@01D6F0EE.1F78A010] BR/pj From: Ranjit Avasarala <ranjitka...@gmail.com<mailto:ranjitka...@gmail.com>> Sent: den 22 januari 2021 18:02 To: Sundbaum Per-Johan (Telenor Sverige AB) <per-johan.sundb...@telenor.se<mailto: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.cs.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.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%7C395dd6c688e0469ac9a008d8befc95a1%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637469339348462085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=16bsqNMbQ6VY04fHKDMWyLYTX%2FZXxY6XepkL4FvEgv4%3D&reserved=0> Sensitivity: Internal Sensitivity: Internal
_______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
