[ previous ] [ next ] [ threads ]
 To :  yate@v...
 From :  Ionut Muntean <ionutm22@g...>
 Subject :  Re: [yate] issue about yate behind nat
 Date :  Tue, 12 Sep 2017 20:22:04 +0300
Maybe I understand this wrong.

But:

In call.route you should have all the info needed about the calling 
party and, computed with some javascript/php script, all info about the 
called number/party this includes IP etc.. In call.route you have the 
initial data that determines the call (by parameters and/or computed by 
scripts). Destination of the call is your responsability to determine. 
You can set some parameters copied by copyparams in call.route so that 
they propagate to call.execute and take further decisions.

Again, maybe I got this wrong, case I appologize for my intervention.


Fun with Yate :)

On 09/12/2017 07:54 PM, Luca Olivetti wrote:
> El 12/09/17 a les 17:50, Ionut Muntean ha escrit:
>>
>> Maybe copyparams will help propagating the value and the parameter 
>> between call.route and call.execute?
>>
>> Just a thought.
>
>
> But in call.route I can only determine the address of the calling 
> party, not of the called one, right?
>
> Bye
>
>>
>>
>>
>> On 09/12/2017 06:45 PM, Luca Olivetti wrote:
>>> El 12/09/17 a les 16:38, Marian Podgoreanu ha escrit:
>>>
>>> Thank you. In call.route I can determine if it is local or remote 
>>> looking at the address, but in call.execute I see no way to check 
>>> the address:
>>>
>>> http://docs.yate.ro/wiki/Call.execute
>>>
>>> (I see by logging that there is an address, but it's the address of 
>>> the calling party, copied from call.route, not the called one).
>>>
>>>
>>> Bye
>>>
>>>> Hi,
>>>>
>>>> 'nat_address' is not handled in call.answered. You must set it 
>>>> during routing.
>>>>
>>>> In section [default] (call.route handler) identify call source 
>>>> (local or public) and set desired nat_address for the incoming call 
>>>> leg.
>>>>
>>>> In section [call.execute] identify call destination (local or 
>>>> public) and set desired nat_address.
>>>> Remember: when handling call.execute make sure you always set the 
>>>> parameter: it may be present from call.route.
>>>> When a call is routed the call.execute message contains parameters 
>>>> set during routing.
>>>>
>>>> Marian
>>>>
>>>> On 09/12/2017 05:02 PM, Luca Olivetti wrote:
>>>>> El 12/09/17 a les 12:29, Marian Podgoreanu ha escrit:
>>>>>> Hi,
>>>>>>
>>>>>> The 'nat_address' is also handled when call is routed.
>>>>>> This will override ysipchan.conf parameter.
>>>>>>
>>>>>> Incoming call leg updates it when call is routed (returns from
>>>>>> routing, before execute)
>>>>>> Outgoing call leg updates it when executed.
>>>>>>
>>>>>> If possible your script detecting IP change may push a custom 
>>>>>> message
>>>>>> into yate notifying new IP.
>>>>>>
>>>>>> You may handle the message in regexroute, set a variable and use it
>>>>>> when needed:
>>>>>>
>>>>>> [extra]
>>>>>> some_custom_message_name=
>>>>>>
>>>>>> [some_custom_message_name]
>>>>>> ${ip}.=;$nat_address=${ip}
>>>>>>
>>>>>> [call.execute]
>>>>>> .*=......;nat_address=$(nat_address)
>>>>>
>>>>> OK, knowing that, I wrote a javascript called on call.execute that 
>>>>> gets
>>>>> the address and sends a custom message.
>>>>>
>>>>> function myExec(msg)
>>>>> {
>>>>> var pippo=DNS.queryA("olivetti.dhis.org",false);
>>>>> Engine.debug(pippo[0]);
>>>>> var ipmsg=new Message("ventoso.nat_address");
>>>>> ipmsg.message="ventoso.nat_address";
>>>>> ipmsg.ip=pippo[0];
>>>>> ipmsg.dispatch();
>>>>> Engine.debug("********************************************************"); 
>>>>>
>>>>> return false;
>>>>> }
>>>>>
>>>>> Message.install(myExec, "call.execute", 50);
>>>>>
>>>>>
>>>>>
>>>>> Then I put a bogus nat_address=1.2.3.4 in ysipchan.conf and modified
>>>>> regexroute.conf
>>>>>
>>>>> [extra]
>>>>> call.execute=50
>>>>> call.answered=50
>>>>> ventoso.nat_address=50
>>>>>
>>>>> [call.execute]
>>>>> .*=echo ============================= call.execute $(nat_address)
>>>>> .*=;osip_Contact=sip:${caller}@c...:56060;maxcall=30000;timeout=300000;nat_address=$(nat_address) 
>>>>>
>>>>>
>>>>>
>>>>> [call.answered]
>>>>> .*=echo ============================= call.answered $(nat_address)
>>>>> .*=;osip_Contact=sip:${caller}@c...:56060;maxcall=30000;timeout=300000;nat_address=$(nat_address) 
>>>>>
>>>>>
>>>>>
>>>>> [ventoso.nat_address]
>>>>> ${ip}.=;$nat_address=${ip}
>>>>>
>>>>> During the call execute I see the correct ip registered and 
>>>>> proposed in
>>>>> the sdp message
>>>>>
>>>>>
>>>>> ------
>>>>> 20170912135609.730930  RTP NAT detected: private
>>>>> '192.168.1.68' public '2.139.210.92'
>>>>> 20170912135609.731615  Could not classify call from 
>>>>> 'elcomluca',
>>>>> wasted 24 usec
>>>>> 20170912135609.733315  Could not route call to 'citofono' in
>>>>> context 'default', wasted 1515 usec
>>>>> 20170912135609.733491  Routed 'citofono' via
>>>>> 'sip/sip:citofono@1...:35060;line=9e12cbb88078dcd(null)'
>>>>> 20170912135609.779701  37.15.61.105
>>>>> 20170912135609.780773 
>>>>> ********************************************************
>>>>> ============================= call.execute 37.15.61.105
>>>>> 20170912135609.784653  Guessed local IP '192.168.10.30' 
>>>>> for
>>>>> remote '192.168.10.30'
>>>>> 20170912135609.785002  Session 'yrtp/292881551' 0xb630dd18
>>>>> bound to 192.168.10.30:57256 +RTCP [0xb630dbd8]
>>>>> 20170912135609.788615  'udp:0.0.0.0:56060' sending 'INVITE
>>>>> sip:citofono@1...:35060;line=9e12cbb88078dcd' 0xb630ba68 to
>>>>> 192.168.10.30:35060 [0xb8145ec8]
>>>>> ------
>>>>> INVITE sip:citofono@1...:35060;line=9e12cbb88078dcd SIP/2.0
>>>>> Max-Forwards: 19
>>>>> Contact: sip:elcomluca@c...:56060
>>>>> Via: SIP/2.0/UDP 192.168.10.30:56060;rport;branch=z9hG4bK346620420
>>>>> From: ;tag=1149214234
>>>>> To: 
>>>>> Call-ID: 1691582082@c...
>>>>> CSeq: 1 INVITE
>>>>> User-Agent: YATE/5.4.0
>>>>> Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO
>>>>> Content-Type: application/sdp
>>>>> Content-Length: 207
>>>>>
>>>>> v=0
>>>>> o=yate 1505224569 1505224569 IN IP4 37.15.61.105
>>>>> s=SIP Call
>>>>> c=IN IP4 37.15.61.105
>>>>> t=0 0
>>>>> m=audio 57256 RTP/AVP 0 8 101
>>>>> a=rtpmap:0 PCMU/8000
>>>>> a=rtpmap:8 PCMA/8000
>>>>> a=rtpmap:101 telephone-event/8000
>>>>> ------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> But when the internal client answers the reply  has the bogus ip.
>>>>> (Note also the empty contact, maybe $(caller) is empty in 
>>>>> call.answered,
>>>>> but it doesn't seem to matter as long as the sdp has the correct ip)
>>>>>
>>>>> ------
>>>>> ============================= call.answered 37.15.61.105
>>>>> 20170912135609.857455  Guessed local IP '192.168.10.30' 
>>>>> for
>>>>> remote '2.139.210.92'
>>>>> 20170912135609.857714  Session 'yrtp/856481178' 0xb6402130
>>>>> bound to 192.168.10.30:57744 +RTCP [0xb6402020]
>>>>> 20170912135609.857824  DataTranslator::attachChain [0xb6402430]
>>>>> '(null)' -> [0xb630e140] 'mulaw' not possible
>>>>> 20170912135609.857900  DataTranslator::attachChain [0xb630e028]
>>>>> 'mulaw' -> [0xb6402548] '(null)' not possible
>>>>> 20170912135609.857979  RTP starting format 'mulaw' 
>>>>> payload 0
>>>>> [0xb6402020]
>>>>> 20170912135609.858571  Choosing started 'audio' format 'mulaw'
>>>>> [0xb6204f88]
>>>>> 20170912135609.860591  'udp:0.0.0.0:56060' sending code 200
>>>>> 0xb6400f10 to 2.139.210.92:50883 [0xb8145ec8]
>>>>> ------
>>>>> SIP/2.0 200 OK
>>>>> Via: SIP/2.0/UDP
>>>>> 192.168.1.68:59136;branch=z9hG4bK-524287-1---9e845219c7968cd5;received=2.139.210.92 
>>>>>
>>>>>
>>>>> From: 
>>>>> ;tag=33e6a613
>>>>> To: 
>>>>> ;tag=301757973
>>>>> Call-ID: bbqc21uiswC-7SxE1sWPrw..
>>>>> CSeq: 2 INVITE
>>>>> Contact: sip:@c...:56060
>>>>> Server: YATE/5.4.0
>>>>> Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO
>>>>> Content-Type: application/sdp
>>>>> Content-Length: 173
>>>>>
>>>>> v=0
>>>>> o=yate 1505224569 1505224569 IN IP4 1.2.3.4
>>>>> s=SIP Call
>>>>> c=IN IP4 1.2.3.4
>>>>> t=0 0
>>>>> m=audio 57744 RTP/AVP 0 101
>>>>> a=rtpmap:0 PCMU/8000
>>>>> a=rtpmap:101 telephone-event/8000
>>>>> h
>>>>>
>>>>> Bye
>>>>
>>> h
>>