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
let say that mediaproxy-ng rtpproxy_offer had flags SP (RTP/SAVPF was
sent to callee). is it necessary to have corresponding flags (e.g. sp)
in rtpproxy_answer call or does mediaproxy-ng remember, what caller's
profile was when corresponding rtpproxy_offer was called?
-- juha
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#348 - Invalide tel INVITE crashes 4.0.3
User who did this - Daniel-Constantin Mierla (miconda)
----------
I injected the invite in a rather simple config file, but tm goes fine with it using latest master and 4.0 branches. Can you give a try with latest branch 4.0 to see if works fine? It might be a side effect of one of the bugs fixed since 4.0.3.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=348#comment1130
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#358 - equals $null and 0 return the same
User who did this - Daniel-Constantin Mierla (miconda)
----------
Should be fixed now on master. Give it a try and see if it works as expected.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=358#comment1129
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#358 - equals $null and 0 return the same
User who did this - Daniel-Constantin Mierla (miconda)
----------
It is not related to #141. I'll try to get a fix for it soon. Meanwhile, one should be able to use the alternatives with:
<code>
if(defined($avp(x)) ...
or
if(!defined($avp(x)) ...
</code>
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=358#comment1128
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.