[OpenSER-Users] Broken "BYE" returned from Asterisk on TLS implementation ?
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Sep 3 15:07:58 CEST 2007
Klaus Darilion schrieb:
>
>
> David Loh schrieb:
>> Hi Klaus,
>>
>> So in order to make it work, the RURI of Asterisk uses should contain
>> "transport=TLS" right.
>
> yes
>
>> if the "transport=TLS" can be appended to the SIP message, the
>> disconnection shall be handle properly ?
>
> yes
>
>>
>> Currently I'm struggling w/ subst/subst_uri ... it's seems the Regex
>> textops module used was slightly different from Unix,
>> I do "subst('/^BYE(.*)SIP\/2\.0/BYE\1;transport=TLS SIP\/2\.0/ ');"
>> but it doesn't work ...
>> I'm not sure if subst able to alter the header but if it doesn't, is
>> there any command that I can use to alter the BYE header ?
>
> There is no need to use subst - just rewrite the request URI. E.g. in
> openser 1.2 the following should work:
>
> if (loose_route()) {
> ...
> if (src_ip == ip.address.of.asterisk) {
> $ru = $ru + ";transport=tls";
I do not know for sure, but maybe it is necessary to reset the duri (may
be set during loose_route()):
resetdsturi();
> }
> ...
> t_relay();
> exit;
> }
>
> regards
> klaus
>
>
>
>>
>> Thanks,
>> David Loh
>>
>> Klaus Darilion wrote:
>>> Route headers are fine - the problem is the RURI of the BYE:
>>>
>>> See the Contact header of the INVITE:
>>> Contact: <sip:davidloh at x.x.80.178:4294;transport=TLS>
>>>
>>> This URI must be used in the RURI of the BYE, but Asterisk uses:
>>> BYE sip:davidloh at x.x.80.178:4294 SIP/2.0
>>>
>>> Thus, the proxy forwards the request with UDP instead of TLS. Thus,
>>> this is a bug in Asterisk. Try update Asterisk. Try looking at
>>> Asterisk Bug tracker for this bug. If you are unlucky, open a bug
>>> report on the Asterisk bug tracker (bugs.digium.com)
>>>
>>> regards
>>> klaus
>>>
>>> David Loh schrieb:
>>>> Hi,
>>>>
>>>> Arrggghh .. that's one of my attempts to eliminate the broken "BYE"
>>>> problem... that's ngrep was captured when I set "modparam("rr",
>>>> "enable_double_rr", "0");",
>>>> I've paste another ngrep to http://pastebin.ca/674450, this time the
>>>> double RR header is enabled.
>>>> And I've posted my .cfg to http://pastebin.ca/Nx0Ss4Fd (key to
>>>> decrypt the post is "openser").
>>>>
>>>> Even though double RR header is enabled, but for BYE it's still
>>>> doesn't process properly :(
>>>> For the .cfg file line #130 onward, I did tried t_relay, forward and
>>>> force_send_socket,
>>>> but none of this will do the trick (force_send_socket was
>>>> complaining TLS error due to missing certificate (?) )
>>>> Would appreciate if anyone could enlighten me why is this happen ?
>>>>
>>>>
>>>> Thanks,
>>>> David Loh
>>>>
>>>>
>>>>
>>>> Klaus Darilion wrote:
>>>>> But the INVITE you posted at http://pastebin.ca/673392 also has
>>>>> only one Record-Route header.
>>>>>
>>>>> regards
>>>>> klaus
>>>>>
>>>>> David Loh schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> Yea, OpenSER proxy was add 2 record-route header for the
>>>>>> INVITE/ACK ...but when asterisk disconnected the call and send BYE
>>>>>> back to OpenSER,
>>>>>> the TLS RR header wasn't present, the only 2 RR header was
>>>>>> "SIP/2.0/UDP <OpenSER_IP>" and "SIP/2.0/UDP <Client_WAN_IP>" ....
>>>>>> I'm puzzled ... is there any command to 'fix' this?
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> David Loh
>>>>>>
>>>>>> Klaus Darilion wrote:
>>>>>>> The openser proxy should add 2 record-route header (TLS and UDP =
>>>>>>> double record route). This is why it does not work.
>>>>>>>
>>>>>>> regards
>>>>>>> klaus
>>>>>>>
>>>>>>> David Loh schrieb:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Greeting.
>>>>>>>>
>>>>>>>> I've been struggle with OpenSER TLS implementation for more than
>>>>>>>> a week, since I've ported from UDP to TLS, everything work fine
>>>>>>>> except the "BYE" request from Asterisk (loose route), my
>>>>>>>> implementation was something like below:
>>>>>>>>
>>>>>>>> [Client] --> [Router] --> [Internet] --> [SIP] --> [Asterisk]
>>>>>>>>
>>>>>>>> My OpenSER.cfg already configured to listen on two port which is
>>>>>>>> :- "tls:eth0:5061" and "udp:eth0:5060", client make p2p or PSTN
>>>>>>>> (or even voicemail) having no problem,
>>>>>>>> but when the callee disconnect the call, caller will never get
>>>>>>>> hang up :(
>>>>>>>>
>>>>>>>> I've attached my ethereal trace/ngrep to pastebin,
>>>>>>>> http://pastebin.ca/673392
>>>>>>>>
>>>>>>>> Wondering if anyone can help me with the broken "BYE" that
>>>>>>>> returned from Asterisk ?
>>>>>>>> Line #131, supposedly this line should have contain 2 Via
>>>>>>>> header, one was "SIP/2.0/UDP" and another "SIP/2.0/TLS",
>>>>>>>> but somehow the TLS via header was gone !! (compare to previous
>>>>>>>> ACK (Line #117) /INVITE (Line #51).
>>>>>>>> Due to the missing TLS via header, OpenSER log file was
>>>>>>>> complaining "protocol/port mis-match".
>>>>>>>>
>>>>>>>> The last BYE request (Line #256) is actually firing from Client,
>>>>>>>> which contain the "TLS" via.
>>>>>>>>
>>>>>>>>
>>>>>>>> I've even tried "force_send_socket" to port 5061 (instead of
>>>>>>>> 5060) from loose route, but it complaining TLS certificate error,
>>>>>>>> since Asterisk doesn't support TLS natively, I've no clue why is
>>>>>>>> the ACK/INVITE/CANCEL work but not BYE.
>>>>>>>> if (loose_route) {
>>>>>>>> ....
>>>>>>>> if(is_method("BYE")) { force_send_socket(IP:5061); }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> Has any one gone through of this kinda OpenSER over TLS +
>>>>>>>> Asterisk setup,
>>>>>>>> I'm really appreciate if you can share your experience with me,
>>>>>>>> or pin point what's the mistakes I made here.
>>>>>>>>
>>>>>>>> Thanks in advance.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> David Loh
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at openser.org
>>>>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list