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> 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. > > > > > > 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> 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 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 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> > Sent: den 22 januari 2021 16:31 > To: Sundbaum Per-Johan (Telenor Sverige AB) <per-johan.sundb...@telenor.se>; > 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 > 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%7C76e15095ceb6408fb20008d8bef77998%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637469317390117199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t2bp3O3eGF1L8K2RQi138cQcQQtBiW80K5%2FsUI4CBqI%3D&reserved=0> > > > > Sensitivity: Internal > >
_______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
