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 mico...@gmail.com 
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 mickaelmarra...@gmail.com 
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 : 
sip:XX;lr;received=sip:XXX:54217%3Btransport%3Dtcp, 
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 : sip: X;lr;received=sip: 
X:54217%3Btransport%3Dtcp, 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 : sip: X;lr;received=sip: 
X:54217%3Btransport%3Dtcp, 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 : sip: 
X;lr;received=sip: X:54217%3Btransport%3Dtcp, 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 
http://www.linkedin.com/in/miconda 





 

-- 

Daniel-Constantin Mierla - 

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 tim.ch...@voicesimplified.com 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 shaherya...@gmail.com
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