Re: [OpenSIPS-Users] CDRTool install

2011-05-31 Thread Tijmen de Mes 

Hi,

No he did not. At least not to me. As far as I know, the patch is still 
not in freeradius.


Tijmen de Mes
AG Projects

Op 5/31/11 7:22 PM, osiris123d schreef:

Did ram ever respond to this question?

--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/CDRTool-install-tp5855130p6423718.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CDRTool install

2011-05-31 Thread osiris123d 
Did ram ever respond to this question?

--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/CDRTool-install-tp5855130p6423718.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Call from Asterisk to Opensips

2011-05-31 Thread sammy 
Tcpdump your call's, and according to the sip response of it, you can locate 
the problem.
If the sip response is 404(Not found), means your ext 1001 prehaps not register 
successful.___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] ACK for RE-INVITE routing

2011-05-31 Thread Dranchuk Alexandr 
Hello everyone!

I'm manually fix Contact headers for caller and callee
party, along with uac_replace_from/uac_replace_to, thus
getting kind of "topology hidding".

Till now all works fine but once RE-INVITE send,
the proper 200 OK responce, and it's routed fine
but ACK sent after reseived 200 OK has no "Route" header
thus, OpenSIPS loose_route() block escaped, and since t_check_trans()
returns true it's trying to send it to wrong direction (looping)

Is it ok if ACK for RE-INVITE can be without "Route" header if
RE-INVITE along with 200 OK responce contain Record-route and Route
headers?

in case of true, is it possible restore Route information by
from_tag/to_tag in OpenSIPS or I should do it by myself in script?

---
Alex Dranchuk
mailto: dav...@davion.kz


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] OpenSIPS bug on CANCEL with early media dialog

2011-05-31 Thread Dranchuk Alexandr 
Hi!

I am using OpenSIP 1.6.4. with Mediaproxy 2.4.4

the scheme for call is:
caller -> OpenSIPS - > callee

Once an INVITE sent from caller, callee response
with 183 followed by 180. Next step is caller send
CANCEL to caller but once CANCEL reached OpenSIPS, it's
stop resending it and provide next error logs:

ERROR:dialog:build_dlg_t: no contact available
ERROR:dialog:send_leg_bye: failed to create dlg_t
CRITICAL:dialog:log_next_state_dlg: bogus event 7 in state 2 for dlg 
0x7fd4378a3400 [1758:121165547] with clid '2f66244400a and tags 'as1d885204' 
'v6y1peXDc00cm'

it looks like OpenSIPS trying to generate a BYE message on early media
dialog, but CANCEL should be forwarded to callee.

so callee keeps ringing for timeout and never receive
missed CANCEL

Similar problem I've found described here also
http://www.mail-archive.com/sr-dev@lists.sip-router.org/msg06034.html



Need your advice.
Thank you.


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CDR Accounting not working from this provider

2011-05-31 Thread Bogdan-Andrei Iancu 

Hi James,

The dialog module does not "see" the BYE, so the dialog is counted as 
still ongoing so no CDR is generated.


Now, about the BYE - by default dialog module exclusively uses a cookie 
(the "did" param in the RR/Route header) to do the matching.


As you can see in the trace, because you do RR for re-INVITE (you 
shouldn't, but normally useless), the cookie is lost - and the device 
sending the BYE is brain-dead enough to "refresh" its route set during 
the reINVITE - even if the RFC says clear that the route set is learned 
only when the dialog is established.


Bottom line, because of the combination of un-nesessary RR and broken 
UA, the cookie gets lost and it does not appear in BYE, so it does not 
match.


A fast fix you can try is to set the matching mode of dialog mode to 
FALLBACK from "did" based matching to SIP-wise matching, so the dialog 
matching will match the BYE against the dialog even if the cookie is 
missing.


Regards,
Bogdan

On 04/23/2011 07:54 AM, jam...@vicidial.com wrote:


I have a new provider that I am evaluating and the built-in CDR 
functionality of the acc module is not working for them. I have tested 
with a second provider and it works fine. I can only assume that 
something somewhere in the SIP dialog is causing it to loose track of 
it. Here is the SIP dialog:


interface: any
filter: (ip) and ( port 5060 )
#
U 2011/04/22 23:06:09.857893 208.38.149.190:5060 -> 208.38.149.182:5060
INVITE sip:18633939336@208.38.149.182;cpd=on SIP/2.0
Via: SIP/2.0/UDP 208.38.149.190:5060;branch=z9hG4bK745a7a33;rport
From: "James P." ;tag=as791c05d3
To: 
Contact: 
Call-ID: 38b57ce271946530476aea3909a8de2b@208.38.149.190
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "James P." 
;privacy=off;screen=no

Date: Sat, 23 Apr 2011 03:12:17 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 264

v=0
o=root 23976 23976 IN IP4 208.38.149.190
s=session
c=IN IP4 208.38.149.190
t=0 0
m=audio 13872 RTP/AVP 18 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

#
U 2011/04/22 23:06:09.858211 208.38.149.182:5060 -> 208.38.149.190:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 208.38.149.190:5060;branch=z9hG4bK745a7a33;rport=5060
From: "James P." ;tag=as791c05d3
To: 
Call-ID: 38b57ce271946530476aea3909a8de2b@208.38.149.190
CSeq: 102 INVITE
Content-Length: 0


#
U 2011/04/22 23:06:09.859762 208.38.149.182:5060 -> 69.30.55.34:5060
INVITE sip:18633939336@69.30.55.34;cpd=on SIP/2.0
Record-Route: 
Via: SIP/2.0/UDP 208.38.149.182;branch=z9hG4bK4956.b46847f.0
Via: SIP/2.0/UDP 
208.38.149.190:5060;received=208.38.149.190;branch=z9hG4bK745a7a33;rport=5060

From: "James P." ;tag=as791c05d3
To: 
Contact: 
Call-ID: 38b57ce271946530476aea3909a8de2b@208.38.149.190
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 69
Remote-Party-ID: "James P." 
;privacy=off;screen=no

Date: Sat, 23 Apr 2011 03:12:17 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 264

v=0
o=root 23976 23976 IN IP4 208.38.149.190
s=session
c=IN IP4 208.38.149.190
t=0 0
m=audio 13872 RTP/AVP 18 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

#
U 2011/04/22 23:06:09.931832 69.30.55.34:5060 -> 208.38.149.182:5060
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 208.38.149.182;branch=z9hG4bK4956.b46847f.0
Via: SIP/2.0/UDP 
208.38.149.190:5060;received=208.38.149.190;branch=z9hG4bK745a7a33;rport=5060

From: "James P." ;tag=as791c05d3
To: 
Call-ID: 38b57ce271946530476aea3909a8de2b@208.38.149.190
CSeq: 102 INVITE
Server: OpenSIPS (1.6.2-notls (i386/linux))
Content-Length: 0


#
U 2011/04/22 23:06:10.974003 69.30.55.34:5060 -> 208.38.149.182:5060
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 208.38.149.182;branch=z9hG4bK4956.b46847f.0
Via: SIP/2.0/UDP 
208.38.149.190:5060;received=208.38.149.190;branch=z9hG4bK745a7a33;rport=5060

Record-Route: 
Record-Route: 
From: "James P." ;tag=as791c05d3
To: ;tag=as7abc238a
Call-ID: 38b57ce271946530476aea3909a8de2b@208.38.149.190
CSeq: 102 INVITE
User-Agent: SIP SWITCH
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 238

v=0
o=root 8881 8881 IN IP4 74.120.95.55
s=session
c=IN IP4 74.120.95.55
t=0 0
m=audio 23416 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

#
U 2011/04/22 23:06:10.974350 208.38.149.182:5060 -> 208.38.149.190:5060
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 
208.38.149.190:5060;received=208.38.149.190;branch=z9hG4bK745a7a33;rport=5060

Record-Route: 
Record-Route: 
From: "James P." ;tag=as791c05d3
To: ;tag=as7abc238a
Call-ID: 38b57ce

Re: [OpenSIPS-Users] mediaproxy losing audio after on-hold?

2011-05-31 Thread Henk Hesselink 

Hi Saúl,

On 4/26/11 9:26 AM, Saúl Ibarra Corretgé wrote:

On 04/23/2011 05:51 PM, Henk Hesselink wrote:

Hi,

We occasionally have calls losing audio after the call has been put on
hold for a while (1-2 minutes) if the caller is behind NAT. What
happens is:

1. caller puts call on-hold
2. after 1-2 minutes the NAT binding times out
3. caller takes call back
4. the REINVITE has new ports
5. mediaproxy doesn't pick up on the new ports
6. no audio

If the caller transfers the call (i.e. a new INVITE) then there is no
problem.

Is there something special we need to do when processing the REINVITE
to tell mediaproxy to pick up the new ports? We use separate calls to
use_media_proxy and end_media_session, we don't use engage_media_proxy.



If you use the separate functions you'll need to call use_media_proxy
also for re-INVITEs, in order to instruct MediaProxy to allocate new
ports and update the ongoing session.


Regards,


Thanks for the info.  Do we also need to call end_media_session before
the call to use_media_proxy?

Regards,

Henk

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users