2008/11/24 Klaus Darilion <[EMAIL PROTECTED]>: > Hi Joan! > > I suggest to create an openser config with the wizard on sipwise.com. > Then analyze this config and you will learn how to apply nat traversal > and use rtpproxy. > Ok, as Klaus have suggested, I've generated the configuration (also with the pattern to route outgoing trough PSTN), and same thing happens ...
>From the logs:
/usr/sbin/kamailio[8755]: Callee is not local - M=INVITE
RURI=sip:[EMAIL PROTECTED] F=sip:[EMAIL PROTECTED]
T=sip:[EMAIL PROTECTED] IP=192.168.253.12
[EMAIL PROTECTED]
/usr/sbin/kamailio[8755]: DBG:nathelper:force_rtp_proxy2_f: proxy reply: E10
/usr/sbin/kamailio[8755]: ERROR:nathelper:force_rtp_proxy2_f:
incorrect port 0 in reply from rtp proxy
As I see, doesn't matter the logic I use for routing (altought the
sipwise, must be better that mine at this point), rtpproxy always
returns me a E10.
> regards
> klaus
>
> Joan schrieb:
>> 2008/11/21 Maxim Sobolev <[EMAIL PROTECTED]>:
>>> Joan,
>>>
>>> The problem seems to be in unbalanced force_rtp_proxy() - which means
>>> that you don't invoke force_rtp_proxy() on INVITE, but call it on
>>> response. This is not allowed, since you would have one way audio in
>>> such case.
>>>
>>> In your script you call force_rtp_proxy() on INVITEs only in the case if
>>> isbflagset(2) is set, while call it on responses if nat_uac_test("19")
>>> returns true on 200 OK. Is it possible that INVITE won't have bflag 9
>>> set, while 200 OK response would trigger nat_uac_test("19"). You should
>>> either fix your NAT detection logic, or use separate onreply blocks for
>>> the cases when you have called force_rtp_proxy() on INVITE and for the
>>> case when you have not.
>> Hello, until this morning I haven't been able to modify any
>> configuration, what I did basically, is to use nat_uac_test("19") in
>> both places.
>>
>> if (is_method("INVITE")) {
>> + if(nat_uac_test("19")) {
>> - if(isbflagset(2)) {########## # behind a NAT
>> log("MIS: Forcing proxy within router 1")
>> force_rtp_proxy();
>> };
>>
>> Watching the logs it seems that nat i detected properly during the
>> INVITE and the force_rtp_proxy is called for the outgoing call, but
>> rtpproxy gives back an answer that kamailio doesn't recognize.
>> I could't find any reference to this value neither.
>>
>> Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]: MIS: Forcing proxy
>> within router 1
>> Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
>> DBG:core:parse_headers: flags=ffffffffffffffff
>> Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
>> DBG:core:get_hdr_field: content_length=399
>> Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
>> DBG:core:get_hdr_field: found end of header
>> Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
>> DBG:nathelper:check_content_type: type <application/sdp> found valid
>> Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
>> DBG:core:parse_headers: flags=40
>> Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
>> DBG:nathelper:force_rtp_proxy2_f: proxy reply: E10
>> Nov 24 09:33:33 pulse /usr/sbin/kamailio[27387]:
>> ERROR:nathelper:force_rtp_proxy2_f: incorrect port 0 in reply from rtp
>> proxy
>>
>>
>> Regards
>> _______________________________________________
>> Users mailing list
>> Users@rtpproxy.org
>> http://lists.rtpproxy.org/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users@rtpproxy.org
> http://lists.rtpproxy.org/mailman/listinfo/users
>
kamailio.cfg
Description: Binary data
_______________________________________________ Users mailing list Users@rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/users
