Hello Sirs, How can I extend subscriber profile with some information like avatar, name, surname, other custom attributes in order to consume those information from a WebRTC app? Is there any standard way or we should use custom code for that?
Thank you.
Best regards, Mihai M
Hi Mihai,
On 03/20/2014 07:22 PM, Mihai Marin wrote:
Hello Sirs, How can I extend subscriber profile with some information like avatar, name, surname, other custom attributes in order to consume those information from a WebRTC app? Is there any standard way or we should use custom code for that?
In fact, there is!
Just add columns to the 'subscriber' table. After you do, the 'auth_db' module provides a way to have them loaded into variables as a byproduct of an authentication challenge:
http://kamailio.org/docs/modules/4.1.x/modules/auth_db.html#idp74512
Of course, if you want to take a different schematic approach, you can always just use 'sqlops' to do your own queries.
-- Alex
Hello Sirs, Sir Alex, Thank you for your quick response.
What is the best way to consume those info from client (ex: chrome)? Adding them as headers in the REGISTER response? How would I do with avatar which is binary?
Thank you.
Best regards, Mihai M
On Fri, Mar 21, 2014 at 1:24 AM, Alex Balashov abalashov@evaristesys.comwrote:
Hi Mihai,
On 03/20/2014 07:22 PM, Mihai Marin wrote:
Hello Sirs,
How can I extend subscriber profile with some information like avatar, name, surname, other custom attributes in order to consume those information from a WebRTC app? Is there any standard way or we should use custom code for that?
In fact, there is!
Just add columns to the 'subscriber' table. After you do, the 'auth_db' module provides a way to have them loaded into variables as a byproduct of an authentication challenge:
http://kamailio.org/docs/modules/4.1.x/modules/auth_db.html#idp74512
Of course, if you want to take a different schematic approach, you can always just use 'sqlops' to do your own queries.
-- Alex
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
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
On 03/20/2014 07:38 PM, Mihai Marin wrote:
What is the best way to consume those info from client (ex: chrome)? Adding them as headers in the REGISTER response?
Yeah, probably.
How would I do with avatar which is binary?
You could include it as a payload in some response, but I think it'd be wiser to simply deal in URL references that pull an avatar image from somewhere else.
Perfect. Thank you.
On Fri, Mar 21, 2014 at 1:40 AM, Alex Balashov abalashov@evaristesys.comwrote:
On 03/20/2014 07:38 PM, Mihai Marin wrote:
What is the best way to consume those info from client (ex: chrome)?
Adding them as headers in the REGISTER response?
Yeah, probably.
How would I do with avatar which is binary?
You could include it as a payload in some response, but I think it'd be wiser to simply deal in URL references that pull an avatar image from somewhere else.
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
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
On 21 Mar 2014, at 00:40, Alex Balashov abalashov@evaristesys.com wrote:
On 03/20/2014 07:38 PM, Mihai Marin wrote:
What is the best way to consume those info from client (ex: chrome)? Adding them as headers in the REGISTER response?
Yeah, probably.
How would I do with avatar which is binary?
You could include it as a payload in some response, but I think it'd be wiser to simply deal in URL references that pull an avatar image from somewhere else.
There's a header for that. From RFC 3261:
20.9 Call-Info
The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the "purpose" parameter. The "icon" parameter designates an image suitable as an iconic representation of the caller or callee. The "info" parameter describes the caller or callee in general, for example, through a web page. The "card" parameter provides a business card, for example, in vCard [ 36] or LDIF [37 ] formats. Additional tokens can be registered using IANA and the procedures in Section 27.
/O
-
Alex Balashov -
Mihai Marin -
Olle E. Johansson