[OpenSIPS-Users] Click to Dial example that comes with OpenSIPS
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Aug 13 19:51:09 CEST 2012
Hi Duane,
That is really strange. Logically speaking, a change in SDP should have
no impact on receiving (or not) a message - the SDP is just payload and
is not even parsed by opensips (unless you ask it from script by using
rtpproxy/mediaproxy/sipmsgops modules). Anyhow, the request should make
it to the main route.
I rather suspect that something else is filtering your SIP traffic,
dropping the INVITEs in the first format :-/ .
Regarding the second issue:
1) the angle brackets are not mandatory by RFC - they should be used
only if you have URI params or a complex display name (which is not your
case here)
2) assuming that the phone does not like TO - it should reply with a 400
Bad request, not a 404 - a 404 represents a routing indication and
routing is done based RURI not TO.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 08/09/2012 06:13 AM, Duane Larson wrote:
> I changed the following in the ctd.sh script
> Changed the default of
> "`printf "v=0\r\no=click-to-dial 0 0 IN IP4
> 0.0.0.0\r\ns=session\r\nc=IN IP4 0.0.0.0\r\nb=CT:1000\r\nt=0
> 0\r\nm=audio 9 RTP/AVP 8 0\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0
> PCMU/8000\r\n"`
> To
> "`printf "v=0\r\no=click2dial 0 0 IN IP4 50.XX.XX.156\r\ns=click2dial
> call\r\nc=IN IP4 173.XX.XX.111\r\nt=0 0\r\nm=audio 12790 RTP/AVP 0 8
> 18 3 4 97 98\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:18
> G729/8000\r\na=rtpmap:97 ilbc/8000\r\na=rtpmap:98 speex/8000\r\n"`
> And now it is making it into the OpenSIPS/SBC's main route. Not sure why.
> I noticed another issue now. My snom phone is receiving the INVITE
> but it is replying with a "404 Not Found" error. (If I test with a
> Jitsi client I don't have the 404 issue)
> This shouldn't happen since the TO header is the correct SIP URI.
> The only thing that can be wrong is that the To: URI is not in <>
> I think the TM MI function t_uac_dlg isn't placing the <> around the
> TO: header URI. Reading the RFC I am not 100% sure if the <> are
> required.
> U 2012/08/08 22:09:13.756976 192.168.88.1:5060
> <http://192.168.88.1:5060> -> 192.168.88.13:3072
> <http://192.168.88.13:3072>
> INVITE sip:9016XX6XX4 at 192.168.88.13:3072
> <http://sip:9016XX6XX4@192.168.88.13:3072> SIP/2.0.
> Max-Forwards: 10.
> Record-Route: <sip:192.168.88.1;r2=on;lr>.
> Record-Route: <sip:99.XX.XX.161;r2=on;lr>.
> Via: SIP/2.0/UDP 192.168.88.1;branch=z9hG4bK3f03.9cb7ee3.0.
> Via: SIP/2.0/UDP 50.XX.XX.156;branch=z9hG4bK3f03.18d165f1.0.
> *To: sip:9016XX6XX4 at irck.com <mailto:sip%3A9016XX6XX4 at irck.com>.*
> From: <sip:controller at ae.com
> <mailto:sip%3Acontroller at ae.com>>;tag=134448175329440.
> CSeq: 1 INVITE.
> Call-ID: 134448175329440.fifouacctd.
> Content-Length: 226.
> User-Agent: OpenSIPS (1.8.0-dev0-tls (x86_64/linux)).
> Contact: <sip:caller at 50.57.54.156:5060
> <http://sip:caller@50.57.54.156:5060>>.
> Content-Type: application/sdp.
> .
> v=0.
> o=click2dial 0 0 IN IP4 50.XX.XX.156.
> 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/08/08 22:09:13.766974 192.168.88.13:3072
> <http://192.168.88.13:3072> -> 192.168.88.1:5060
> <http://192.168.88.1:5060>
> SIP/2.0 404 Not found.
> Via: SIP/2.0/UDP 192.168.88.1;branch=z9hG4bK3f03.9cb7ee3.0.
> Via: SIP/2.0/UDP 50.XX.XX.156;branch=z9hG4bK3f03.18d165f1.0.
> From: <sip:controller at ae.com
> <mailto:sip%3Acontroller at ae.com>>;tag=134448175329440.
> To: <sip:9016726924 at irock.com <mailto:sip%3A9016726924 at irock.com>>.
> Call-ID: 134448175329440.fifouacctd.
> CSeq: 1 INVITE.
> User-Agent: snom821/8.7.3.10 <http://8.7.3.10>.
> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
> PRACK, MESSAGE, INFO, UPDATE.
> Allow-Events: talk, hold, refer, call-info.
> Supported: timer, replaces, from-change.
> Content-Length: 0.
>
> On Fri, Jul 27, 2012 at 3:24 PM, <duane.larson at gmail.com
> <mailto:duane.larson at gmail.com>> wrote:
>
> Very sure. Normal calls are working with clients behind the
> OpenSIPS/SBC.
>
>
>
>
> On , Bogdan-Andrei Iancu <bogdan at opensips.org
> <mailto:bogdan at opensips.org>> wrote:
> >
> >
> >
> >
> >
> >
> > Duane,some stupid question : are you sure your opensips is
> > listening on the given IP:port ? have you check with netstat ?
> > also have you checked with netstat also if there is traffic queued
> > on the sockets ?
> >
> >
> >
> > Regards,
> >
> >
> > Bogdan-Andrei Iancu
> > OpenSIPS Founder and Developer
> > http://www.opensips-solutions.com
> >
> >
> > On 07/27/2012 12:48 AM, Duane Larson wrote:
> > Oh yeah. My first email has the SIPTrace from the
> > OpenSIPS/SBC. So I am logged into the OpenSIPS/SBC and did the
> > NGREP. So I see it SIP invite (99.XX.XX.161 is the IP of the
> > OpenSIPS/SBC). I would even let you log into the OpenSIPS/SBC
> > and see it for yourself. Makes no sense.
> >
> >
> >
> > 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 <mailto:sip%3A9016XXXXX at irock.com>.
> >
> > From: sip:controller at ae.com
> <mailto:sip%3Acontroller at ae.com>>;tag=134274001013257.
> >
> > CSeq: 1 INVITE.
> >
> > Call-ID: 134274001013257.fifouacctd.
> >
> > Content-Length: 155.
> >
> > User-Agent: OpenSIPS (1.8.0-dev0-tls (x86_64/linux)).
> >
> > Contact: sip:caller at 50.57.54.156:5060
> <http://sip:caller@50.57.54.156:5060>>.
> >
> > 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120813/59d9668a/attachment.htm>
More information about the Users
mailing list