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
