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> 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 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 > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
