a sip ua that only supports rtp/avp is sending invite to jssip ua and i make this kind of offer on it:
Oct 27 17:28:50 rautu /usr/sbin/sip-proxy[8156]: INFO: ===== making rtpproxy_offer(co1SP+r)
outgoing invite looks fine and jssip is happy with it. it replies with this kind of 200 ok:
SIP/2.0 200 OK Record-Route: sip:192.98.102.30;transport=tcp;lr;savpf;pm Via: SIP/2.0/WS 192.98.102.30;branch=z9hG4bK3347.f9aa980aac8a49f0059ae9f7691cafe5.0;i=2 Via: SIP/2.0/TCP 188.67.67.5:51375;received=192.98.102.30;branch=z9hG4bK85a22944e41f9cac;rport=57018 To: sip:jh@test.tutpro.com;tag=egmrvkni4j From: sip:test@test.tutpro.com;tag=943af1f962302e2d Call-ID: 96dabb8d0412d3f5 CSeq: 9113 INVITE Contact: sip:jh@test.tutpro.com;gr=urn:uuid:954352ab-46f2-4eef-b771-9c5ff4900843 Content-Type: application/sdp Content-Length: 1056
v=0 o=- 3981174047439634860 2 IN IP4 127.0.0.1 s=- t=0 0 a=msid-semantic: WMS dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dm m=audio 47207 RTP/SAVPF 0 8 101 c=IN IP4 188.67.67.5 a=rtcp:37710 IN IP4 188.67.67.5 a=candidate:4130326675 1 udp 2113937151 188.67.67.5 47207 typ host generation 0 a=candidate:1742886165 1 udp 2113937151 192.98.102.30 33266 typ host generation 0 a=candidate:4130326675 2 udp 2113937150 188.67.67.5 37710 typ host generation 0 a=candidate:1742886165 2 udp 2113937150 192.98.102.30 45924 typ host generation 0 a=ice-ufrag:CwQt9Ssgev6ee3Bj a=ice-pwd:JDANa2ehlkWeV4qxjG5Kqb3c a=mid:audio a=sendrecv a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:LPd/5pIsj4VD6peaLVALE83pz7z3d5DCU1El0cRm a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ssrc:449829374 cname:CagN0RFDWP+bPWyu a=ssrc:449829374 msid:dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dm dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dma0 a=ssrc:449829374 mslabel:dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dm a=ssrc:449829374 label:dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dma0
i then make this kind of answer on the 200 ok:
Oct 27 17:28:55 rautu /usr/sbin/sip-proxy[8160]: INFO: ===== making rtpproxy_answer(co2sp+r)
for some reason mediaproxy-ng does not like the answer and reports:
Oct 27 17:28:55 rautu mediaproxy-ng[17684]: [96dabb8d0412d3f5 - z9hG4bK85a22944e41f9cac] Got LOOKUP, but no usable callstreams found
still mediaproxy-ng works as it should and calling ua gets this kind of 200 ok:
T 2013/10/27 17:28:55.915677 192.98.102.30:5060 -> 192.98.102.30:57018 [AP] SIP/2.0 200 OK. Record-Route: sip:192.98.102.30;transport=tcp;lr;savpf;pm. Via: SIP/2.0/TCP 188.67.67.5:51375;received=192.98.102.30;branch=z9hG4bK85a22944e41f9cac;rport=57018. To: sip:jh@test.tutpro.com;tag=egmrvkni4j. From: sip:test@test.tutpro.com;tag=943af1f962302e2d. Call-ID: 96dabb8d0412d3f5. CSeq: 9113 INVITE. Contact: sip:jh@test.tutpro.com;gr=urn:uuid:954352ab-46f2-4eef-b771-9c5ff4900843. Content-Type: application/sdp. Content-Length: 789. . v=0. o=- 3981174047439634860 2 IN IP4 192.98.102.30. s=-. t=0 0. a=msid-semantic: WMS dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dm. a=ice-lite. m=audio 50226 RTP/AVP 0 8 101. c=IN IP4 192.98.102.30. a=mid:audio. a=sendrecv. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=ssrc:449829374 cname:CagN0RFDWP+bPWyu. a=ssrc:449829374 msid:dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dm dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dma0. a=ssrc:449829374 mslabel:dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dm. a=ssrc:449829374 label:dUI8U3367dUaz5NAE6cZpoEf3xcoEvApx6dma0. a=rtcp:50227. a=ice-ufrag:3AXaewTZ. a=ice-pwd:kFLmjvPdBqGhKHfgNnbHhLuljrtw. a=candidate:G16dyvMo2umxYq42 1 UDP 2130706432 192.98.102.30 50226 typ host. a=candidate:G16dyvMo2umxYq42 2 UDP 2130706431 192.98.102.30 50227 typ host.
why does mediaproxy-ng claim that does not find any usable streams even when it does proper job on the 200 ok and the call works fine?
-- juha
On 10/27/13 11:45, Juha Heinanen wrote:
why does mediaproxy-ng claim that does not find any usable streams even when it does proper job on the 200 ok and the call works fine?
Possibly it's because of the non-standard RTCP port in the answer. Technically this is supported but the implementation is more of a hack than anything else for the time being.
cheers
Richard Fuchs writes:
Possibly it's because of the non-standard RTCP port in the answer. Technically this is supported but the implementation is more of a hack than anything else for the time being.
looks like the rtpc port number in 200 ok is not "non-standard" anymore. from rfc 3605 dated october 2003:
The SIP messages use the encoding defined in SDP [RFC2327] to describe the IP addresses and TCP or UDP ports used by the various media. Audio and video are typically sent using RTP [RFC3550], which requires two UDP ports, one for the media and one for the control protocol (RTCP). SDP carries only one port number per media, and states that "other ports used by the media application (such as the RTCP port) should be derived algorithmically from the base media port." RTCP port numbers were necessarily derived from the base media port in older versions of RTP (such as [RFC1889]), but now that this restriction has been lifted, there is a need to specify RTCP ports explicitly in SDP.
-- juha
On 10/28/13 11:59, Juha Heinanen wrote:
Richard Fuchs writes:
Possibly it's because of the non-standard RTCP port in the answer. Technically this is supported but the implementation is more of a hack than anything else for the time being.
looks like the rtpc port number in 200 ok is not "non-standard" anymore. from rfc 3605 dated october 2003:
That's not what I meant with "non standard". Maybe I should have said: explicitly specified as a port not equal to the implicit port. But that would have been too long of a sentence :)
cheers
-
Juha Heinanen -
Richard Fuchs