[OpenSER-Users] OpenSER with TLS - method BYE = protocol/port mismatch ??
David Loh
davidloh at vyke.com
Thu Aug 23 11:30:04 CEST 2007
Hi Daniel,
I've found this http://bugs.digium.com/view.php?id=1491 , as I'm using
quite ancient version of Asterisk (v1.2.19),
could it be the reason why is the BYE not able to deliver to UAC ?
Regards,
David Loh
David Loh wrote:
> Hi Daniel,
>
> Here's my ngrep result:
> # ngrep -qt -W byline port 5060
> interface: eth0 (FF.FFF.FFF.0/255.255.255.192)
> filter: (ip or ip6) and ( port 5060 )
> ------------------------------------------------------------------------
> * trimmed, please refer to earlier post*
> .
> ------------------------------------------------------------------------
>
> As you can see the last few BYE request wasn't able to deliver to UAC
> (or UAC failed to response),
> and it kept looping. For me the packets look fine, really no clue
> what's could go wrong here :(
>
>
> Thanks,
> David Loh
>
>
>
> Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> please send the request uri as well and the details about the IP
>> communication (source/destination address, port).
>>
>> use:
>>
>> ngrep -qt -W byline port 5060
>>
>> the replace the IPs with something suggestive to protect your privacy.
>>
>> Daniel
>>
>>
>> On 08/21/07 14:28, David Loh wrote:
>>> Hi Daniel,
>>>
>>> Thanks for the reply, here's my INVITE and BYE packet, I tcpdump-ed
>>> and and use wireshark to export as txt, so the format might be abit
>>> off.
>>>
>>> 1) Invite from OpenSER to Asterisk via port 5060, asterisk return a
>>> 200. And the call successfully established
>>> ------------------------------------------------------------------------
>>>
>>> Record-Route: <sip:%OpenSER_IP%;r2=on;lr;ftag=1247871f;nat=yes>
>>> Record-Route:
>>> <sip:%OpenSER_IP%:5061;transport=tls;r2=on;lr;ftag=1247871f;nat=yes>
>>> Via: SIP/2.0/UDP %OpenSER_IP%;branch=z9hG4bKe42e.ff11ae32.0;i=52
>>> Via: SIP/2.0/TLS
>>> %UAC_LAN_IP%:23323;received=%UAC_WAN_IP%;branch=z9hG4bK-d87543-2820ee009262b500-1--d87543-;rport=3135
>>>
>>> Max-Forwards: 69
>>> Contact: <sip:davidloh@%UAC_WAN_IP%:3135;transport=TLS>
>>> To: "001"<sip:001@%SIP_Domain%>
>>> From: "ser"<sip:davidloh@%SIP_Domain%>;tag=1247871f
>>> Call-ID: Zjc4OWJhZGNiMDUxNjQ5Y2I2ZDU3NTc4NGY2Y2RmOGQ.
>>> CSeq: 1 INVITE
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>> SUBSCRIBE, INFO
>>> Content-Type: application/sdp
>>> User-Agent: eyeBeam release 1004p stamp 31962
>>> Content-Length: 239
>>> ------------------------------------------------------------------------
>>>
>>>
>>> 2) Here's the BYE, from Asterisk to OpenSER.
>>> ------------------------------------------------------------------------
>>>
>>> Via: SIP/2.0/UDP %Asterisk_IP%:5060;branch=z9hG4bK0ca1ab09;rport
>>> Route:
>>> <sip:%OpenSER_IP%;r2=on;lr;ftag=1247871f;nat=yes>,<sip:%OpenSER_IP%:5061;transport=tls;r2=on;lr;ftag=1247871f;nat=yes>
>>>
>>> From: "001"<sip:001@%SIP_Domain%>;tag=as0492a9d0
>>> To: "ser"<sip:davidloh@%SIP_Domain%>;tag=1247871f
>>> Call-ID: Zjc4OWJhZGNiMDUxNjQ5Y2I2ZDU3NTc4NGY2Y2RmOGQ.
>>> CSeq: 102 BYE
>>> User-Agent: Asterisk PBX
>>> Max-Forwards: 70
>>> Content-Length: 0
>>> ------------------------------------------------------------------------
>>>
>>>
>>> 3) And then, OpenSER passing the BYE to UAC...
>>> ------------------------------------------------------------------------
>>>
>>> Record-Route: <sip:%OpenSER_IP%;lr;ftag=as0492a9d0>
>>> Via: SIP/2.0/UDP %OpenSER_IP%;branch=z9hG4bK5e.1195fd8.0
>>> Via: SIP/2.0/UDP %Asterisk_IP%:5060;branch=z9hG4bK0ca1ab09;rport=5060
>>> From: "001"<sip:001@%SIP_Domain%>;tag=as0492a9d0
>>> To: "ser"<sip:davidloh@%SIP_Domain%>;tag=1247871f
>>> Call-ID: Zjc4OWJhZGNiMDUxNjQ5Y2I2ZDU3NTc4NGY2Y2RmOGQ.
>>> CSeq: 102 BYE
>>> User-Agent: Asterisk PBX
>>> Max-Forwards: 69
>>> Content-Length: 0
>>> ------------------------------------------------------------------------
>>>
>>>
>>> I think the "protocol/port mismatch" happened right after (3)
>>> because from my ethereal trace,
>>> after short while (perhaps timeout), Asterisk will re-initiate a
>>> "BYE" and pass to OpenSER (packet #2), and OpenSER will forward it
>>> to UAC (packet #3),
>>> but somehow UAC doesn't response an "ACK" to OpenSER that why from
>>> my ethereal trace, packet #2 and #3 kept looping.
>>>
>>> Any thoughts ?
>>>
>>>
>>> Thanks in advance.
>>>
>>> Regards,
>>> David Loh
>>>
>>>
>>>
>>> Daniel-Constantin Mierla wrote:
>>>> Hello,
>>>>
>>>> can you paste the BYE here (you can catch it with ngrep if it is
>>>> not coming via tls, e.g., from asterisk)? Also, the invite going to
>>>> asterisk will be good.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 08/20/07 07:50, David Loh wrote:
>>>>> Hi All,
>>>>>
>>>>> Good day, I'm new to this mailing list :-)
>>>>>
>>>>> I've setup an OpenSER server with TLS implementation, so far I
>>>>> tested everything works fine,
>>>>> but there's strange problem for "BYE" request, from the openser's
>>>>> log it always complaint:
>>>>> "Aug 19 22:58:40 ser /sbin/openser[16171]:
>>>>> WARNING:get_send_socket: protocol/port mismatch"
>>>>>
>>>>> Here's my implementation:
>>>>> UA -> OpenSER -> Asterisk (as RTP) -> OpenSER -> UA
>>>>> On OpenSER I've two port opened which is Udp 5060 and TCP 5061 (TLS).
>>>>> My UA is Eyebeam v1.5 and the CA certificate (self-signed) already
>>>>> installed into IE "Trusted RootCA Certificates".
>>>>> So far I've tested p2p and pstn calls (and call to playback
>>>>> balance/asterisk), but the problem is unless UA disconnect the
>>>>> call (initiate BYE),
>>>>> otherwise if remote party (p2p/pstn/asterisk) initiate BYE
>>>>> request, my UA will forever stay connected until I disconnect the
>>>>> call manually.
>>>>>
>>>>> So far I've identified the BYE request from remote party will go
>>>>> into Loose Route, and I've place a xlog to display the R-Uri..
>>>>> here's the log from openser: (notes: if UA dial '001' will
>>>>> playback his/her balance from asterisk)
>>>>> -------------------------------------------------------------------------------------------------------------
>>>>>
>>>>> Aug 19 22:58:31 ser /sbin/openser[16189]: DBG: INVITE from client
>>>>> sip:%user%@%domain% (%UA_IP%) - p2p call
>>>>> Aug 19 22:58:31 ser /sbin/openser[16189]: DBG: INVITE
>>>>> F-[sip:%user%@%domain%] T-[sip:001@%domain%] IP-[%UA_IP%] SUCCESSFUL
>>>>> Aug 19 22:58:32 ser /sbin/openser[16189]: DBG: INVITE from client
>>>>> sip:%user%@%domain% (%UA_IP%)
>>>>> Aug 19 22:58:32 ser /sbin/openser[16189]: DBG: INVITE from client
>>>>> sip:%user%@%domain% (%UA_IP%) - p2p call
>>>>> Aug 19 22:58:32 ser /sbin/openser[16189]: DBG: INVITE
>>>>> F-[sip:%user%@%domain%] T-[sip:001@%domain%] IP-[%UA_IP%] SUCCESSFUL
>>>>> Aug 19 22:58:32 ser /sbin/openser[16189]: DBG:
>>>>> [sip:%user%@%domain%](%UA_IP%) ACK [sip:001@%domain%] relayed
>>>>> LOOSE ROUTE
>>>>> Aug 19 22:58:32 ser /sbin/openser[16189]: DBG: ruri
>>>>> [sip:001@%Asterisk_IP%] relayed LOOSE ROUTE
>>>>> Aug 19 22:58:40 ser /sbin/openser[16171]: DBG:
>>>>> [sip:001@%domain%](%Asterisk_IP%) BYE [sip:%user%@%domain%]
>>>>> relayed LOOSE ROUTE
>>>>> Aug 19 22:58:40 ser /sbin/openser[16171]: DBG: ruri
>>>>> [sip:%user%@%domain%:%UA_Port%] relayed LOOSE ROUTE
>>>>> Aug 19 22:58:40 ser /sbin/openser[16171]: WARNING:get_send_socket:
>>>>> protocol/port mismatch <<<=============
>>>>> Aug 19 22:58:41 ser /sbin/openser[16177]: DBG:
>>>>> [sip:001@%domain%](%Asterisk_IP%) BYE [sip:%user%@%domain%]
>>>>> relayed LOOSE ROUTE
>>>>> Aug 19 22:58:41 ser /sbin/openser[16177]: DBG: ruri
>>>>> [sip:%user%@%UA_IP%:%UA_Port%] relayed LOOSE ROUTE
>>>>> Aug 19 22:58:42 ser /sbin/openser[16181]: DBG:
>>>>> [sip:001@%domain%](%Asterisk_IP%) BYE [sip:%user%@%domain%]
>>>>> relayed LOOSE ROUTE
>>>>> Aug 19 22:58:42 ser /sbin/openser[16181]: DBG: ruri
>>>>> [sip:%user%@%UA_IP%:%UA_Port%] relayed LOOSE ROUTE
>>>>> ....... (repeat the last 4 lines N times )
>>>>> -------------------------------------------------------------------------------------------------------------
>>>>>
>>>>> Below is my openser.cfg, loose route section
>>>>> -------------------------------------------------------------------------------------------------------------
>>>>>
>>>>> ###############
>>>>> # Loose route #
>>>>> ###############
>>>>> if(loose_route()) {
>>>>> if(has_totag() && (is_method("INVITE") || is_method("ACK"))) {
>>>>> if(nat_uac_test("19") || search("^Route:.*;nat=yes")) {
>>>>> fix_nated_contact();
>>>>> }
>>>>> }
>>>>>
>>>>> xlog("L_INFO", "DBG: [$fu]($si) $rm [$tu] relayed LOOSE
>>>>> ROUTE");
>>>>> xlog("L_INFO", "DBG: ruri [$ru] relayed LOOSE ROUTE");
>>>>> t_relay();
>>>>>
>>>>> exit;
>>>>> }
>>>>> -------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Had anyone encountered the same problems before ? Do you mind to
>>>>> share your experience with me ?
>>>>> Your help are greatly appreciated, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20070823/0b98594f/attachment.htm
More information about the Users
mailing list