[OpenSIPS-Users] Click to Dial example that comes with OpenSIPS

Mon Jul 23 18:54:46 CEST 2012

That is correct there is no answer to the INVITE and it doesn't appear to  
even enter the main route of the OpenSIPS config. I have xlogs set up in  
the opensips script and I never see the INVITE enter. Here is another sip  
trace from the php-sip click to call program and for some reason this  
INVITE does go through the main route without issue.

#
U 2012/07/23 11:49:04.398750 50.XX.XX.156:5060 -> 99.XX.XX.161:5060
INVITE sip:9016XX6XX4 at 192.168.88.13:3072;line=996he62l SIP/2.0.
Record-Route:  
<sip:50.XX.XX.156;lr;ftag=34533;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=38a.ff1a8d45>.
Via: SIP/2.0/UDP 50.XX.XX.156;branch=z9hG4bK10f3.c6fade97.0.
Via: SIP/2.0/UDP  
50.XX.XX.54:5065;received=50.XX.XX.54;rport=5065;branch=z9hG4bK185398.
From: <sip:c2c at 50.XX.XX.54>;tag=34533.
To: <sip:9016XX6XX4 at irock.com>.
Call-ID: 78ecbf1cd5542c12fe2293da14517b38 at 50.57.75.54.
CSeq: 20 INVITE.
Contact: <sip:c2c at 50.XX.XX.54:5065>.
Content-Type: application/sdp.
Max-Forwards: 69.
User-Agent: PHP SIP.
Subject: click2call.
Content-Length: 225.
P-hint: outbound->inbound .
P-hint: Route[6]: mediaproxy .
.
v=0.
o=click2dial 0 0 IN IP4 50.57.75.54.
s=click2dial call.
c=IN IP4 173.XX.XX.111.
t=0 0.
m=audio 12790 RTP/AVP 0 8 18 3 4 97 98.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:97 ilbc/8000.
a=rtpmap:98 speex/8000.

#
U 2012/07/23 11:49:04.398750 99.XX.XX.161:5060 -> 50.XX.XX.156:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 50.XX.XX.156;branch=z9hG4bK10f3.c6fade97.0.
Via: SIP/2.0/UDP  
50.XX.XX.54:5065;received=50.XX.XX.54;rport=5065;branch=z9hG4bK185398.
From: <sip:c2c at 50.XX.XX.54>;tag=34533.
To: <sip:9016Xx6xx4 at irock.com>.
Call-ID: 78ecbf1cd5542c12fe2293da14517b38 at 50.XX.xx.54.
CSeq: 20 INVITE.
Server: OpenSIPS (1.8.0-notls (x86_64/linux)).
Content-Length: 0.
.

So I am not sure why the first sip trace INVITE I sent isn't being  
processed but the one above is. Very weird.

I haven't tried to send it to another OpenSIPS server because I really  
don't have any other server to test with.

On , Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:

> Hi Duane,

> You mean there is no answer to that INVITE ? When you tried to
> send the INVITE to another opensips, have you noticed errors in
> the logs (like parsing errors)?

> Regards,

> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com

> On 07/21/2012 07:45 AM, duane.larson at gmail.com wrote:
> Has anyone used the ctd.sh example that comes with
> Opensips in the "example" folder? I am trying to use it and the
> INVITE gets sent out but nothing happens. I even tried with
> sending the INVITE to an OpenSIPS server and the OpenSIPS server
> never even sees it enter the main route even though I see that the
> INVITE is making it to the server because an NGREP shows it making
> it. It doesn't make much sense. I even did a debug and don't see
> anything showing that OpenSIPS sees the INVITE.

> Here is the INVITE that is generated from ctd.sh

> U 2012/07/19 18:20:13.486847 50.XX.XX.156:5060 ->
> 99.XX.XX.161:5060

> INVITE sip:9016XXXXX at 192.168.88.13:3072;line=g2hfphrk SIP/2.0.

> Via: SIP/2.0/UDP 50.57.54.156;branch=z9hG4bKaab1.6c7ffd84.0.

> To: sip:9016XXXXX at irock.com.

> From: ;tag=134274001013257.

> CSeq: 1 INVITE.

> Call-ID: 134274001013257.fifouacctd.

> Content-Length: 155.

> User-Agent: OpenSIPS (1.8.0-dev0-tls (x86_64/linux)).

> Contact: .

> Content-Type: application/sdp.

> .

> v=0.

> o=click-to-dial 0 0 IN IP4 0.0.0.0.

> s=session.

> c=IN IP4 0.0.0.0.

> b=CT:1000.

> t=0 0.

> m=audio 9 RTP/AVP 8 0.

> a=rtpmap:8 PCMA/8000.

> a=rtpmap:0 PCMU/8000.

> Is anyone else out there using anything else to do Click to
> Dial????

> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120723/ef015195/attachment.htm>