Re: [SR-Users] Wrong location entries when using usrloc with Mongo

2015-01-31 Thread Mickael Marrache
Hi,

 

The log entries are all of the form:

 

DEBUG: db_mongodb [mongodb_dbase.c:948]: db_mongodb_delete(): delete filter 
document: { "expires" : { "$date" : 1422728781000 }, "expires" : { "$date" : 0 
} }

 

Mickael

 

From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of 
Daniel-Constantin Mierla
Sent: Friday, January 30, 2015 4:28 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] Wrong location entries when using usrloc with Mongo

 

I checked quickly the code and mongo c api, it looks ok. Can you see a debug 
message with content like:

 

... delete filter document: ...

 

when running with debug=3? If yes, can you send it over to check if is correct?

 

Cheers,

Daniel

 

On Fri, Jan 30, 2015 at 10:45 AM, Daniel-Constantin Mierla  
wrote:

Hello,

 

it seems that the fileds inside the object are deleted, not the entire object. 
The match was done on username and ruid for deletion, both of them are missing.

 

I will look at the mongo api to see if something was set wrong there for the 
delete command.

 

Cheers,

Daniel

 

 

On Fri, Jan 30, 2015 at 9:54 AM, Mickael Marrache  
wrote:

I forgot to precise that I allow only one contact per AOR.

 

modparam("registrar", "max_contacts", 1)

save("location", "0x04")

 

From: Mickael Marrache [mailto:mickaelmarra...@gmail.com] 
Sent: Friday, January 30, 2015 10:51 AM
To: sr-users@lists.sip-router.org
Subject: Wrong location entries when using usrloc with Mongo

 

Hi,

 

I start with no location nor in Mongo, nor in memory. My UA registers 
successfully and I can see the location entry in Mongo. Then, I close my UA 
which unregisters (by setting Expires header to 0). Then, I open the app again 
and a new registration is made.

 

The entry after first registration. Looks okay.

 

{ "_id" : ObjectId("54cb38f684e58133783f2b42"), "username" : "A", "contact" : 
"sip:A@192.168.1.3:54217;rinstance=DFAEBBC7;transport=tcp", "expires" : 
ISODate("2015-01-30T08:55:34Z"), "q" : -1, "callid" : 
"297EC55073A07BF78F0C05822A6CCDFB47E48705", "cseq" : 8809, "flags" : 0, 
"cflags" : 0, "user_agent" : "Acrobits Softphone Business/3.1", "received" : 
"sip:XXX:54217;transport=tcp", "path" : 
"", 
"socket" : "udp:X:5060", "methods" : 4751, "last_modified" : 
ISODate("2015-01-30T07:55:34Z"), "ruid" : "uloc-54cb38df-3378-2", "instance" : 
null, "reg_id" : 0 }

 

The same entry after un register (Expires 0). Note that the username field is 
missing. In any case, I expected the entry to be deleted.

 

{ "_id" : ObjectId("54cb38f684e58133783f2b42"), "expires" : 
ISODate("2015-01-30T08:56:51Z"), "q" : -1, "cseq" : 8811, "flags" : 0, "cflags" 
: 0, "user_agent" : "Acrobits Softphone Business/3.1", "received" : "sip: 
X:54217;transport=tcp", "path" : "", "socket" : "udp: X:5060", 
"methods" : 4751, "last_modified" : ISODate("2015-01-30T07:56:51Z"), "callid" : 
"297EC55073A07BF78F0C05822A6CCDFB47E48705", "instance" : null, "reg_id" : 0, 
"contact" : "sip:A@192.168.1.3:54217;rinstance=DFAEBBC7;transport=tcp" }

 

The entries after second registration. The new entry looks okay. But, the old 
entry is still here.

 

{ "_id" : ObjectId("54cb38f684e58133783f2b42"), "expires" : 
ISODate("2015-01-30T08:56:51Z"), "q" : -1, "cseq" : 8811, "flags" : 0, "cflags" 
: 0, "user_agent" : "Acrobits Softphone Business/3.1", "received" : "sip: 
X:54217;transport=tcp", "path" : "", "socket" : "udp: X:5060", 
"methods" : 4751, "last_modified" : ISODate("2015-01-30T07:56:51Z"), "callid" : 
"297EC55073A07BF78F0C05822A6CCDFB47E48705", "instance" : null, "reg_id" : 0, 
"contact" : "sip:A@192.168.1.3:54217;rinstance=DFAEBBC7;transport=tcp" }

 

{ "_id" : ObjectId("54cb3a7884e581337a25b895"), "username" : "A", "contact" : 
"sip:A@192.168.1.3:54217;rinstance=DFAEBBC7;transport=tcp", "expires" : 
ISODate("2015-01-30T09:02:00Z"), "q" : -1, "callid" : 
"297EC55073A07BF78F0C05822A6CCDFB47E48705", "cseq" : 8813, "flags" : 0, 
"cflags" : 0, "user_agent" : "Acrobits Softphone Business/3.1", "received" : 
"sip: X:54217;transport=tcp", "path" : "", "socket" : 
"udp: X:5060", "methods" : 4751, "last_modified" : 
ISODate("2015-01-30T08:02:00Z"), "ruid" : "uloc-54cb38df-337a-1", "instance" : 
null, "reg_id" : 0 }

 

The issue is the entry is not deleted after un registering.

 

I precise that registrations are dispatched over multiple registrars with all 
accesses the same Mongo cluster.

 

Thanks,

Mickael

 

 

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users





 

-- 

Daniel-Constantin Mierla - http://www.asipto.com

http://twitter.com/#!/miconda - http://www.linkedin.com/in/micond 
 





 

-- 

Daniel-Constantin Mierla - http://www.asipto.com

http://twitter.com/#!/miconda - http://www.linkedin.

[SR-Users] Issue with dlg_setflag vs. setflag

2015-01-31 Thread Anthony Messina
I'm currently using Kamailio built from master@e59db79 and have been following 
the recent threads about the dialog module as I'm moving toward adding dialog 
support for presence and CDRs in my setup.

However, I seem to have come across an issue where dlg_setflag() does nothing, 
while setflag() works properly with the following (trimmed) script.  So for 
now, I issue setflag(FLT_DIALOG) for INVITE rather than 
dlg_setflag(FLT_DIALOG).

Is there something I'm missing about dlg_setflag()?


#!define FLT_DIALOG 4
request_route {
route(REQINIT);
route(NATDETECT);
if(is_method("CANCEL")) {
if(t_check_trans()) {
route(RELAY);
}
exit;
}
route(WITHINDLG);
if(t_precheck_trans()) {
t_check_trans();
exit;
}
t_check_trans();
route(AUTH);
remove_hf("Route");
if(is_method("INVITE|SUBSCRIBE"))
record_route();
if(is_method("INVITE")) {
setflag(FLT_ACC);
# Enable dialog support (dlg_setflag not working)
#dlg_setflag(FLT_DIALOG);
setflag(FLT_DIALOG);
}
route(SIPOUT);
route(PRESENCE);
route(REGISTRAR);
if($rU==$null) {
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
route(PSTN);
route(LOCATION);
route(RELAY);
}

route[WITHINDLG] {
if(!has_totag()) return;
if(loose_route()) {
route(DLGURI);
if(is_method("BYE")) {
setflag(FLT_ACC);
setflag(FLT_ACCFAILED);
# Testing dialog flag
xlog("L_INFO", "Completed $dlg(from_uri) to 
$dlg(to_uri) - $DLG_lifetime duration\n");
} else if(is_method("ACK")) {
route(NATMANAGE);
} else if(is_method("NOTIFY")) {
record_route();
}
route(RELAY);
exit;
}
if(is_method("SUBSCRIBE") && uri==myself) {
route(PRESENCE);
exit;
}
if(is_method("ACK")) {
if(t_check_trans()) {
route(RELAY);
exit;
} else {
exit;
}
}
sl_send_reply("404","Not Found");
exit;
}

-- 
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E


signature.asc
Description: This is a digitally signed message part.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] What could cause an intermittent fault (28) with http_query()?

2015-01-31 Thread Brandon Armstead
What happens if you run the daemon in foreground / high verbosity ?  Paste 
error logs back here.  My guess would be there is some kind of blocking 
happening, ie DNS lookup possibly try using an alternate resolver ?

Sent from my iPhone

> On Jan 30, 2015, at 10:19 AM, Tim Chubb  wrote:
> 
> Hi All
>  
> I seem to be experiencing an intermittent fault with the utils http_query() 
> method.  We are implementing a routing and white list component that is 
> accessed via a REST api, however i have observed several occasions where this 
> is logged:
> Jan 30 16:04:17 vs-kam-prod02 /usr/local/sbin/kamailio[13184]: ERROR: utils 
> [functions.c:149]: http_query(): failed to perform curl (28)
>  
> The indicated error number (28) seems to suggest a timeout is occurring with 
> curl, however examining a capture of network traffic when this happens shows 
> that a http request is not sent from the server to the destination at all, 
> usually attempting a second call results in everything working correctly.
>  
> As stated its intermittent in its nature and so I cannot reliably trigger 
> this issue, other than through sheer repetition, so any ideas as to what 
> could be causing this issue would be gratefully received,
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Video Key-Frame Request using RTCP FIR or SIP INFO message

2015-01-31 Thread Gonzalo Gasca Meza
Hi Muhammad

Can you comment if initially endpoints are receiving what is necessary to
start sending Media at signaling level. For example: Successful ICE and
SRTP-SDES/DTLS negotiation.

I see two issues here:
a) Establish a successful call
b) Once call is established how to deal with packet loss. Check this paper:
http://static.googleusercontent.com/media/research.google.com/sv//pubs/archive/41611.pdf

>From your email: "Force WebRTC client (running on Chrome / Firefox) to
honor SIP INFO message and issue a key-frame in RTP video stream in
response to this SIP request?"

WebRTC in the browser depends on a upper transport layer in your case a SIP
stack. Example: sipml5, sip.js, etc. Hence you need to modify that part
there; so your signaling stack should interact with the Browser Media
Engine upon recieving SIP INFO.

Questions:
1. I would suggest to start a conversation in discuss-webrtc in Google
Groups.
   -Which SIP stack are you using on the WebRTC client side?
   -Can you upload logs from WebRTC client and SIP client.
(WebRTC/SIP/SIP stack)
   -Topology and browser version
   -Codec: VP8/H.264. This will help us to understand how media is
handled.

If you do a packet capture can you still see Browser sending Video to SIP
Client after those initial 5-7 seconds. (Check Webrtc logs/packet capture)

Some details about WebRTC handling packet loss.

https://groups.google.com/forum/#!topic/discuss-webrtc/0ZbxO05a9Zk

HTH

Thanks
-G




On Thu, Jan 29, 2015 at 2:56 PM, Muhammad Shahzad 
wrote:

> Hi,
>
> This may be a bit out of focus topic for this forum but i am posting it
> here anyway with hope that some guru would shed some light on it and point
> me to right direction.
>
> The problem is that i want to establish video call between a webrtc and a
> sip client using kamailio (for signalling) and RTPEngine (for media relay).
> Both signalling and the audio stream seems to work perfectly fine The
> remote video on webrtc client side (i.e. video stream from sip client)
> takes about 20-30 seconds to establish but once it starts it works fine.
> However, the remote video on sip client side (i.e. video stream from webrtc
> client) starts almost immediately (within 3-5 seconds) but it gets stuck
> after 1 or 2 seconds, then it goes blank after about 30 seconds.
>
> After a long discussion with sip client developer, we now understand the
> fact that sip client sends a request for so called key-frame, which is
> ignored by webrtc client. This request is sent through both RTCP stream and
> SIP INFO message.
>
> The SIP INFO message seems to be pointless as media is internally managed
> by chrome/firefox and these browsers don't give us such sophisticated
> access and control over media streams. Please let me know if this
> assumption is wrong.
>
> For the RTCP stream based request (RTCP-FIR), i only see "Invalid RTCP
> packet type" error message in RTPEngine logs (not sure if it drops this
> packet or relay it anyway).
>
> Does anyone has any idea on how can we either,
>
> 1. Force WebRTC client (running on Chrome / Firefox) to honor SIP INFO
> message and issue a key-frame in RTP video stream in response to this SIP
> request?
>
> OR
>
> 2. Force RTPEngine to accept RTCP-FIR and issue key-frame in RTP video
> stream on webrtc client's behalf?
>
> If there is any other solution to this, please feel free to share.
>
>
> Thank you.
>
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users