Re: [Sip-implementors] SDP answer with c=0.0.0.0 and a=sendrecv behavior
Comment at end On 7/7/17 11:17 AM, Sourav Dhar Chaudhuri wrote: Hi, There is a B2B sitting between A (Caller) and B ( callee) 1) A has sent INVITE without SDP towards B 2)B has responded 200OK with SDP offer for INVITE to A. Refer below the SDP offer v=0 o=- 16408314 16408314 IN IP4 ABC.DEF.GH.IJ s=- c=IN IP4 192.168.119.69 t=0 0 a=sendrecv m=audio 3866 RTP/AVP 8 0 18 96 c=IN IP4 192.168.119.69 b=RR:0 b=RS:0 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=maxptime:40 3)Then A has sent ACK with SDP answer. v=0 o=- 8 1 IN IP4 192.168.95.142 s=- c=IN IP4 0.0.0.0 t=0 0 a=sendrecv m=audio 24208 RTP/AVP 8 0 96 c=IN IP4 0.0.0.0 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=maxptime:40 Now this ACK is not passed to B by the B2B sitting between them. Is the SDP answer is valid? As it can be seen in connection line 0.0.0.0 but media attribute is sendrecv. Is sendrecv possible here? There is another successful case 1) A has sent INVITE without SDP towards B 2) B has responded 200OK with SDP offer for INVITE to A. Refer below the SDP offer v=0 o=- 1498048404 1498048404 IN IP4 192.168.95.97 s=Basic Session c=IN IP4 192.168.95.97 t=0 0 m=audio 22780 RTP/AVP 18 8 0 96 99 a=rtpmap:96 AMR/8000 a=fmtp:96 octet-align=1 a=rtpmap:99 telephone-event/8000 a=ptime:20 3)Then A has sent ACK with SDP answer. v=0 o=- 2 1 IN IP4 192.168.95.142 s=Basic Session c=IN IP4 0.0.0.0 t=0 0 m=audio 23148 RTP/AVP 8 0 99 a=rtpmap:99 telephone-event/8000 a=ptime:20 This time the ACK is passed successfully to B by the B2B sitting between them. Here it can be seen in SDP answer that connection line is 0.0.0.0 but no sendrecv. What is your theory here? Is it that the B2BUA is objecting to sendrecv with 0.0.0.0, yet is ok when no directionality is specified? (But where the default is still sendrecv.) I don't offhand see anything objectionable about either of these. ISTM that the B2BUA is being overly picky. And in any case, even if it finds something wrong, just dropping the ACK is not realistic way of dealing with it. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] SDP answer with c=0.0.0.0 and a=sendrecv behavior
Hi, There is a B2B sitting between A (Caller) and B ( callee) 1) A has sent INVITE without SDP towards B 2) B has responded 200OK with SDP offer for INVITE to A. Refer below the SDP offer v=0o=- 16408314 16408314 IN IP4 ABC.DEF.GH.IJs=-c=IN IP4 192.168.119.69t=0 0a=sendrecvm=audio 3866 RTP/AVP 8 0 18 96c=IN IP4 192.168.119.69b=RR:0b=RS:0a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:96 telephone-event/8000a=fmtp:96 0-15a=maxptime:40 3) Then A has sent ACK with SDP answer. v=0o=- 8 1 IN IP4 192.168.95.142s=-c=IN IP4 0.0.0.0t=0 0a=sendrecvm=audio 24208 RTP/AVP 8 0 96c=IN IP4 0.0.0.0a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:96 telephone-event/8000a=fmtp:96 0-15a=maxptime:40 Now this ACK is not passed to B by the B2B sitting between them.Is the SDP answer is valid? As it can be seen in connection line 0.0.0.0 but media attribute is sendrecv. Is sendrecv possible here? There is another successful case 1) A has sent INVITE without SDP towards B 2) B has responded 200OK with SDP offer for INVITE to A. Refer below the SDP offer v=0o=- 1498048404 1498048404 IN IP4 192.168.95.97s=Basic Sessionc=IN IP4 192.168.95.97t=0 0m=audio 22780 RTP/AVP 18 8 0 96 99a=rtpmap:96 AMR/8000a=fmtp:96 octet-align=1a=rtpmap:99 telephone-event/8000a=ptime:20 3) Then A has sent ACK with SDP answer. v=0o=- 2 1 IN IP4 192.168.95.142s=Basic Sessionc=IN IP4 0.0.0.0t=0 0m=audio 23148 RTP/AVP 8 0 99a=rtpmap:99 telephone-event/8000a=ptime:20 This time the ACK is passed successfully to B by the B2B sitting between them. Here it can be seen in SDP answer that connection line is 0.0.0.0 but no sendrecv. Thanks,Sourav ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] SDP answer with c=0.0.0.0 and a=sendrecv behavior
Hi, There is a B2B sitting between A (Caller) and B ( callee) 1) A has sent INVITE without SDP towards B 2) B has responded 200OK with SDP offer for INVITE to A. Refer below the SDP offer v=0o=- 16408314 16408314 IN IP4 ABC.DEF.GH.IJs=-c=IN IP4 192.168.119.69t=0 0a=sendrecvm=audio 3866 RTP/AVP 8 0 18 96c=IN IP4 192.168.119.69b=RR:0b=RS:0a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:96 telephone-event/8000a=fmtp:96 0-15a=maxptime:40 3) Then A has sent ACK with SDP answer. v=0o=- 8 1 IN IP4 192.168.95.142s=-c=IN IP4 0.0.0.0t=0 0a=sendrecvm=audio 24208 RTP/AVP 8 0 96c=IN IP4 0.0.0.0a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:96 telephone-event/8000a=fmtp:96 0-15a=maxptime:40 Now this ACK is not passed to B by the B2B sitting between them.Is the SDP answer is valid? As it can be seen in connection line 0.0.0.0 but media attribute is sendrecv. Is sendrecv possible here? There is another successful case 1) A has sent INVITE without SDP towards B 2) B has responded 200OK with SDP offer for INVITE to A. Refer below the SDP offer v=0o=- 1498048404 1498048404 IN IP4 192.168.95.97s=Basic Sessionc=IN IP4 192.168.95.97t=0 0m=audio 22780 RTP/AVP 18 8 0 96 99a=rtpmap:96 AMR/8000a=fmtp:96 octet-align=1a=rtpmap:99 telephone-event/8000a=ptime:20 3. Then A has sent ACK with SDP answer. v=0o=- 2 1 IN IP4 192.168.95.142s=Basic Sessionc=IN IP4 0.0.0.0t=0 0m=audio 23148 RTP/AVP 8 0 99a=rtpmap:99 telephone-event/8000a=ptime:20 This time the ACK is passed successfully to B by the B2B sitting between them. Here it can be seen in SDP answer that connection line is 0.0.0.0 but no sendrecv. Thanks,Sourav ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
