Hi ! Usually its's a normal release Reason: SIP;cause=200;text="User Triggered" BR/pj
From: Ranjit Avasarala <ranjitka...@gmail.com> Sent: den 5 februari 2021 16:49 To: Arun Tagare <arun.taga...@gmail.com> Cc: 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 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<mailto: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<mailto: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<mailto:pkyzi...@alum.mit.edu>> > Sent: den 22 januari 2021 23:44 > To: Sundbaum Per-Johan (Telenor Sverige AB) > <per-johan.sundb...@telenor.se<mailto:per-johan.sundb...@telenor.se>>; > Ranjit Avasarala <ranjitka...@gmail.com<mailto:ranjitka...@gmail.com>>; > 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 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<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><mailto: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><mailto: <mailto:%0b>> sip%3a%2b46708xxx...@ims.mnc008.mcc240.3gppnetwork.org<mailto:sip%253a%252b46708xxx...@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><mailto: <mailto:%0b>> sip%3a%2b46708xxxx...@ims.mnc008.mcc240.3gppnetwork.org<mailto:sip%253a%252b46708xxxx...@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><mailto: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><mailto:per-johan.sundb...@telenor.se<mailto:per-johan.sundb...@telenor.se>>>; > > sip-implementors@lists.cs.columbia.edu<mailto:sip-implementors@lists.cs.columbia.edu><mailto:sip-implementors@lists.c<mailto:sip-implementors@lists.c> > > s.columbia.edu<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.columbia.edu%2F&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917523899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uXxik6d1tlMs0FzbBlnWo%2BkQ4jwRvoQAPZN9ob7fKyo%3D&reserved=0>> > > 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><mailto:Sip-implementors@lists.c<mailto:Sip-implementors@lists.c> > > s.columbia.edu<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.columbia.edu%2F&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917533899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C%2BMuUK6C%2B8fl0P6%2BN9MOMS3n8%2FZRL55ZTmh%2FjQ2%2BDGk%3D&reserved=0>> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.cs.columbia.edu<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.cs.columbia.edu%2F&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917533899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7rsuplqpKlh2souqZHQawMp3J%2FuXs%2Bknypa8s3FEGDM%3D&reserved=0>%2Fmailman%2Flistinfo%2Fsip-implementors&data=04% > > 7C01%7Cper-johan.sundbaum%40telenor.se<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F40telenor.se%2F&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917543896%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=z%2FK4Gr00l11XWlNiuG8Qw97swvb0B%2Bgo0BmeKhoHo5k%3D&reserved=0>%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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feur02.safelinks.protection.out%2F&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917553891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hpAyXb9A0oxbI5srFqAqn825LagYfqW7%2BGSZu8eWprM%3D&reserved=0> > > look.com/?url=https%3A%2F%2Flists.cs.columbia.edu%2Fmailman%2Flistinfo<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flook.com%2F%3Furl%3Dhttps%253A%252F%252Flists.cs.columbia.edu%252Fmailman%252Flistinfo&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917553891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XGe2lDt1BYaDtMaHM6WXXl0EDq0z%2BZG2NchZE0rFvCU%3D&reserved=0> > > %2Fsip-implementors&data=04%7C01%7Cper-johan.sundbaum%40telenor.se<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F40telenor.se%2F&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917563883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W3OwzX9ZgQeP%2B%2Bx2KaBHLGZmYKXORzkGmHqb8ThIoaE%3D&reserved=0> > > %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<mailto:Sip-implementors@lists.cs.columbia.edu> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.cs.columbia.edu<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.cs.columbia.edu%2F&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917563883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BA8zOQjq1GC7yTye9cl7ML%2BXlQL2RxCAYXmKQHU09qY%3D&reserved=0>%2Fmailman%2Flistinfo%2Fsip-implementors&data=04% > > 7C01%7Cper-johan.sundbaum%40telenor.se<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2F40telenor.se%2F&data=04%7C01%7Cper-johan.sundbaum%40telenor.se%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917573878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=21B5DMD7W9fBklg6OngELR9vOiIbEbBde%2BaouHxlCpQ%3D&reserved=0>%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<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%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917583875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kjrAA3aYIWNSmd0VBAQFlDTXb33ZEvHDaZgCJ5tqcmk%3D&reserved=0> > -- With Regards Arun A. Tagare +91 9449 029729 _______________________________________________ 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%7C31fbf9b9573f46270ced08d8c9edabd8%7C1676489c5c7246b7ba639ab90c4aad44%7C1%7C0%7C637481369917583875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kjrAA3aYIWNSmd0VBAQFlDTXb33ZEvHDaZgCJ5tqcmk%3D&reserved=0> Sensitivity: Internal _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
