no it won't, as issue with codecs mismatch and not full/partial offer. Either of them have to change their codec / PT mapping
Just curious, does BYE have the reason for call termination? Regards Ranjit On Thu, Feb 4, 2021 at 11:13 PM Arun Tagare <arun.taga...@gmail.com> wrote: > Hi All, > > Will it solve if you send FULL offer when UE receive re-Invite w/o SDP > > pCSCF --------- VoLTE-phone > > INVITE -> > > With SDP offer > > <- 180 Ringing > > <- 200OK with SDP answer > > ACK -> > > re-INVITE -> > > without SDP > > <- 200OK with SDP Offer <<<<<< Here instead of sending > negotiated offer try sending full offer > > ACK -> > > With SDP answer > > > > > > On Mon, Jan 25, 2021 at 7:12 PM Sundbaum Per-Johan (Telenor Sverige AB) < > per-johan.sundb...@telenor.se> wrote: > > > 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 > > > > > -- > > With Regards > > Arun A. Tagare > +91 9449 029729 > _______________________________________________ > 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
