Yep, I can use the CLI functionnalities.
I reply asap :)
thanks Klaus,
.Sam.
On Thu, Dec 4, 2008 at 1:36 PM, Klaus Darilion <klaus.mailinglists(a)pernau.at
wrote:
> Does the Thoms phone have a logging interface (maybe pcap like SNOM phones,
> or syslog ...).
>
> Then you could verify if the Thomson phone "sees" the INVITE
>
> klaus
>
> Samuel Muller schrieb:
>
>> Hello,
>>
>> I tried all the ways you told :
>>
>> I moved the SIP phone at home, which I don't have any firewall and it does
>> not pass through the entreprise fw.
>> so the SIP phone is directly connected to the proxy.
>>
>> it registers well, no pbm, but the problem stay.
>> Impossible to make a call to the Thomson.
>>
>> INVITE from any SIP phone (hard or soft, I tried with a Linksys, then a SJ
>> Phone) through Kamailio is not going to the Thomson.
>> All the others SIP stuff are working (Linksys to SJ Phone, ...).
>>
>> I tried many configuration changes into the Thomson ST2030,
>> unsuccessfully.
>> I mean it's not a NAT problem ...
>>
>> Here you are the SIP messages in the kamailio debug from SJ Phone
>> (0123451011) to the f***in' Thomson (0123451014) :
>>
>> Dec 1 20:49:36 kamailio[29592]: -> incoming SIP buffer message:
>>
>> INVITE sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> <mailto:
>> sip%3A0123451014(a)sip.720.fr <sip%253A0123451014(a)sip.720.fr>> SIP/2.0
>> Via: SIP/2.0/UDP 192.168.1.3 <http://192.168.1.3
>> >;rport;branch=z9hG4bKc0a801030000004549343fcf39c16ac5000000f0
>> Content-Length: 264
>> Contact: <sip:0123451011@192.168.1.3:5060 <
>>
http://sip:0123451011@192.168.1.3:5060>>
>> Call-ID: 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3 <mailto:
>> 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3>
>> Content-Type: application/sdp
>> CSeq: 2 INVITE
>> From: "sambook"<sip:0123451011@sip.720.fr
<sip%3A0123451011(a)sip.720.fr><mailtolt;mailto:
>> sip%3A0123451011(a)sip.720.fr <sip%253A0123451011(a)sip.720.fr>
>> >>;tag=409529589751851917
>> Max-Forwards: 70
>> To: <sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>
<mailto:
>> sip%3A0123451014(a)sip.720.fr <sip%253A0123451014(a)sip.720.fr>>>
>> User-Agent: SJphone/1.60.299a/L (SJ Labs)
>> Proxy-Authorization: Digest
username="0123451011",realm="sip.720.fr <
>>
http://sip.720.fr>"t;",
>> nonce="493440fb0000001024641d0bca47789c4c6f68d81262f201",uri="
>> sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> <mailto:
>> sip%3A0123451014(a)sip.720.fr <sip%253A0123451014(a)sip.720.fr>>">>",
>>
>>
response="b8df3912d21ddd8aca40c0bf254bbdcf",cnonce="40952964931016109891",qop="auth",nc="00000001"
>>
>> v=0
>> o=- 3437149775 3437149775 IN IP4 192.168.1.3 <http://192.168.1.3>
>> s=SJphone
>> c=IN IP4 192.168.1.3 <http://192.168.1.3>
>> t=0 0
>> a=direction:active
>> m=audio 49168 RTP/AVP 0 8 3 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:3 GSM/8000
>>
>>
>> Dec 1 20:49:36 kamailio[29592]: -> outgoing SIP buffer message:
>>
>> INVITE sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> <mailto:
>> sip%3A0123451014(a)sip.720.fr <sip%253A0123451014(a)sip.720.fr>> SIP/2.0
>> Via: SIP/2.0/UDP 192.168.1.3 <http://192.168.1.3
>> >;rport;branch=z9hG4bKc0a801030000004549343fcf39c16ac5000000f0
>> Content-Length: 264
>> Contact: <sip:0123451011@192.168.1.3:5060 <
>>
http://sip:0123451011@192.168.1.3:5060>>
>> Call-ID: 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3 <mailto:
>> 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3>
>> Content-Type: application/sdp
>> CSeq: 2 INVITE
>> From: "sambook"<sip:0123451011@sip.720.fr
<sip%3A0123451011(a)sip.720.fr><mailtolt;mailto:
>> sip%3A0123451011(a)sip.720.fr <sip%253A0123451011(a)sip.720.fr>
>> >>;tag=409529589751851917
>> Max-Forwards: 69
>> To: <sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>
<mailto:
>> sip%3A0123451014(a)sip.720.fr <sip%253A0123451014(a)sip.720.fr>>>
>> User-Agent: SJphone/1.60.299a/L (SJ Labs)
>> Proxy-Authorization: Digest
username="0123451011",realm="sip.720.fr <
>>
http://sip.720.fr>"t;",
>> nonce="493440fb0000001024641d0bca47789c4c6f68d81262f201",uri="
>> sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> <mailto:
>> sip%3A0123451014(a)sip.720.fr <sip%253A0123451014(a)sip.720.fr>>">>",
>>
>>
response="b8df3912d21ddd8aca40c0bf254bbdcf",cnonce="40952964931016109891",qop="auth",nc="00000001"
>>
>> v=0
>> o=- 3437149775 3437149775 IN IP4 192.168.1.3 <http://192.168.1.3>
>> s=SJphone
>> c=IN IP4 192.168.1.3 <http://192.168.1.3>
>> t=0 0
>> a=direction:active
>> m=audio 49168 RTP/AVP 0 8 3 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:3 GSM/8000
>>
>> In the attached file, the full kamailio debug level 9.
>>
>> It seems that nothing is coming to the Thomson (I don't have any hub where
>> I can sniff the frames).
>>
>> "The truth is out there" ... :/
>>
>>
>> .desperate house Sam.
>>
>>
>>
>> On Mon, Dec 1, 2008 at 1:44 PM, Samuel Muller <sml(a)720.fr <mailto:
>> sml(a)720.fr>
wrote:
>>
>> many thanks Klaus,
>>
>> I'll check tonight at home, and will reply to you after.
>>
>> sincerely, thanks !
>>
>> .Sam.
>>
>>
>>
>>
>> On Mon, Dec 1, 2008 at 1:28 PM, Klaus Darilion
>> <klaus.mailinglists(a)pernau.at
<mailto:klaus.mailinglists@pernau.at>>
>> wrote:
>>
>> Hi Samuel!
>>
>> The INVITE sent from Kamailio to Thomson phone does not trigger
>> any response. There are various possible reasons:
>>
>> 1. INVITE is ignored by Thomson phone
>> 2. INVITE does not make it thorugh to the Thomson phone
>> 2.1 either sent to the wrong port
>> 2.2 or the NAT binding time out, thus NAT does not forward
>> correctly
>>
>> Thus, verify if the INVITE is received by the NAT device and
>> forwarded to the Thomson phone (e.g. putting a hub between the
>> NAT router and the phone). REGISTER with the Thomson phone and
>> then immediately after call it (linksys->thomson) - this should
>> work as the binding should be alive just after the registration.
>>
>> The problem could also be caused by a buggy NAT router or VPN
>> client or firewall ALGs.
>>
>> To further debug this issue you could also try the Thomson phone
>> with another VoIP service (e.g.
iptel.org <http://iptel.org> or
>>
ekiga.net <http://ekiga.net>) or try the Thomson phone from
>>
>> another access (e.g. try it at home bypassing your company FW/NAT).
>>
>> You could also try to avoid port 5060, e.g. Put the proxy on
>> port 5678 and also use other ports locally for the SIP clients.
>> SIP ALGs (application level gateways) usually are triggered by
>> port 5060.
>>
>>
>> regards
>> klaus
>>
>>
>> Samuel Muller schrieb:
>>
>>
>>
>> On Mon, Dec 1, 2008 at 12:24 PM, Klaus Darilion
>> <klaus.mailinglists(a)pernau.at
>> <mailto:klaus.mailinglists@pernau.at>
>> <mailto:klaus.mailinglists@pernau.at
>> <mailto:klaus.mailinglists@pernau.at>>
wrote:
>>
>>
>>
>> Samuel Muller schrieb:
>>
>> Hey Klaus,
>>
>> first, some answers :
>>
>> -> when a thomson is the callee, there's no ringing
>> even if
>> indicated into the SIP message.
>> -> when a thomson is the caller, no problem, there's
>> a ring, and
>> the call is ok with audio.
>>
>>
>> Please be a bit more specific: What does "no ring" mean?
>> No "180 ringing" response from callee to caller?
>> "180 ringing" response but no "ring-back" at
the
>> caller's client?
>>
>>
>> oups, sorry, I mean : SIP messages are ok, there is all the
>> sig process.
>>
>> the architecture is :
>> linksys + thomson -> cisco 827 -> SDSL -> our backbone which
>> have a firewall for VPN (so NAT and NAPT are applied here),
>> then the kamailio with a public ip.
>>
>> you have the 100 trying, 180 ringing in the SIP message, but
>> there's no ring-back tone for the callee.
>>
>> in the attached file :
>> linksys to linksys, where all the call process is ok (sip +
>> rtp)
>> thomson to linksys, idem
>> linksys to thomson, sip ok but rtp apparently not.
>> I forgot the firewall for the vpn, rtp proxying is
>> required, sorry - so yes rtp proxy must be used.
>>
>> regards,
>>
>> .Sam.
>>
>>
>>