[Kamailio-Users] FW: Call Hangup from Caller-End not working with TLS

[Ali Jawad]

Hi Klaus

You are referring to line 17 right ? That part of traffic is from
openser to the pstn gw ..and both of those are UDP..should it be
transport=tls there or transport=udp?
Thanks

With Regards

Ali Jawad

System Administrator

Splendor Telecom (www.splendor.net)

Beirut, Lebanon

Phone: +961 1 373725

Fax: +961 1 375554


-----Original Message-----
From: Klaus Darilion [mailto:klaus.mailinglists at pernau.at] 
Sent: 2008-08-29 14:34
To: Ali Jawad
Cc: users at lists.kamailio.org
Subject: Re: [Kamailio-Users] FW: Call Hangup from Caller-End not
working with TLS

1. INVITE:

Contact: 
<sip:username at IP.OF.LAN.GW:2949;transport=UDP;rinstance=D98C1DD404B2008F
980980E97E42F8EC;nat=yes>.

As you see the caller announces UDP as contact. Either a bug in the 
caller client or do you rewrite the contact in openser?

Further it is strange that the caller sends frmo 127.0.0.1 (Via header, 
SDP) but announces a different IP in contact.

regards
klaus

Ali Jawad schrieb:
> Dear All
> 
> Please find below the call setup from my softphone to my cell phone,
The
> setup is as follows:
> 
> LAN -> Office Gateway <--TLS--->Openser<--UDP-->PSTN GW
> 
> I got the trace below by applying
> 
> ngrep  -W byline -T username -q -d eth0
> 
> http://pastebin.com/m2a78a27f
> 
> I did the same trace for a udp call and it seemed identical to me, as
> you can see in the lower part of the trace that a BYE packet is being
> sent to the softphone however the transport is being indicated as UDP
> not TLS..is this normal ?
> Any clues apart from that ?
> 
> Thanks
> 
> -----Original Message-----
> From: Klaus Darilion [mailto:klaus.mailinglists at pernau.at] 
> Sent: 2008-08-28 18:13
> To: Ali Jawad
> Cc: users at lists.kamailio.org
> Subject: Re: [Kamailio-Users] FW: Call Hangup from Caller-End not
> working with TLS
> 
> Hi!
> 
> Send us an ngrep dump: ngrep -P "" -W byline port 5060
> 
> Although this will show us only the UDP part (as TLS is encrypted) but

> may still show as the problem.
> 
> Which SIP client do you use?
> 
> regards
> klaus
> 
> Ali Jawad schrieb:
>> Hi All
>>
>> I am using using openser 1.3..if I make a call between two softphones
> on 
>> the same lan or a a pstn call to my mobile phone..and the 
>> called/receiver party does hang-up the call. It works fine in UDP
mode
> 
>> and the call get's hang-up. However in TLS mode this does not work. 
>> Anything I might have missed here? Since both udp and tls use the
same
> 
>> routes, and voice is fine and no one way audio ..etc.
>>
>> I notice this http://pastebin.com/m38c979f6 on rtp proxy. However in
> the 
>> logs of openser I can't see any errors.
>>
>> However on the wire shark I can see icmp destination
> unreachable...port 
>> unreachable.
>>
>> I would have said it is a NAT issue. However it works for simple UDP.
>>
>>  
>>
>> However I did notice the following in the logs
>>
>>  
>>
>> Aug 28 13:41:01 [8565] DBG:tm:set_timer: relative timeout is 4000000
>>
>> Aug 28 13:41:01 [8565] DBG:tm:insert_timer_unsafe: [7]: 0xb6137794 
>> (45900000)
>>
>> Aug 28 13:41:01 [8565] DBG:tm:retransmission_handler: 
>> retransmission_handler : done
>>
>> Aug 28 13:41:02 [8564] DBG:core:parse_msg: SIP Request:
>>
>> Aug 28 13:41:02 [8564] DBG:core:parse_msg:  method:  <BYE>
>>
>> Aug 28 13:41:02 [8564] DBG:core:parse_msg:  uri:     
>>
>
<sip:michofr at 193.227.186.146:3218;transport=UDP;rinstance=D98C1DD404B200
> 8F980980E97E42F8EC;nat=yes>
>> Aug 28 13:41:02 [8564] DBG:core:parse_msg:  version: <SIP/2.0>
>>
>> Aug 28 13:41:02 [8564] DBG:core:parse_headers: flags=2
>>
>> Aug 28 13:41:02 [8564] DBG:core:parse_via_param: found param type
232,
> 
>> <branch> =
>>
>>  
>>
>> Shouldn't the transport=TLS ?
>>
>>  
>>
>>  
>>
>> Regards
>>
>>
>>
>
------------------------------------------------------------------------
>> _______________________________________________
>> Users mailing list
>> Users at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.