27 Oct
2013
27 Oct
'13
5:45 p.m.
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
28 Oct
28 Oct
5:18 p.m.
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
5:59 p.m.
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
9:54 p.m.
On 10/28/13 11:59, Juha Heinanen wrote:
Richard Fuchs writes:
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
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:
4046
days inactive
4047
days old
3 comments
2 participants
participants (2)
-
Juha Heinanen -
Richard Fuchs