Hi Vadim!
Unfortunately we don't have an environment that allows "follow me"
capabibility testing here.
Anyway, a look on SIP packages exchanged with just the inicial
changes pointed below confirmed my suspicion.
Considering that, I've changed methods "ph_answer_request" and
"eXosip_answer_call" to accept an additional parameter "char*
answer_contact" that will have a value only on "follow me" scenario
(it will be NULL on all other cases).
The patch follows attached and, as I've said, I made the necessary
tests and study (reading RFC 3261) to have a feeling that it's all
ok, but as our server don't handle "302 Moved Temporarily" response
codes, I'm not completely sure that this will work perfectly.
Can you please have a look on it ?
Thanks and best regards,
Mauro.
Mauro Sergio Ferreira Brasil escreveu:
Hi Vadim!
I started to make the patch regarding "phLineSetFollowMe" today,
and I have some questions.
I have already a patch with the following items:
1- The "followme" field was added to "phVLine_T" structure;
2- The "vline_free" method deallocates "followme" field;
3- "phLineSetFollowMe" method was added to "phapi-old.c", and two
blocks were enabled again (I've took off the "if 0" condition of
both) on this same file so the "follow me" actually happen;
The problem is that I'm suspicious that the changes on
"ph_answer_request" method will break the logic that made this code
work on prior versions.
Methods "ph_answer_request" and "eXosip_answer_call" used to have a
"contact" parameter that on most of cases will be calculated now by
"owsip_account_contact_get". Unfortunately, on "follow me"
scenario, I think the "contact" will not be available by this method.
Am I right ?
If all my assumptions are right, I'm thinking to add the "contact"
parameter again to both methods ("ph_answer_request" and
"eXosip_answer_call"), and call "owsip_account_contact_get" inside
the last one only when this "contact" parameter is NULL, what will
happen on every condition except the "follow me" scenario.
What you think ?
Thanks and best regards,
Mauro.
Mauro Sergio Ferreira Brasil escreveu:
Wow...
Thanks a lot for the very quick answer Vadim.
I'll send you the patch regarding "phLineSetFollowMe" method as
soon as I get this codes migrated, what I expect won't take too
much time.
Thanks again and best regards,
Mauro.
Vadim Lebedev escreveu:
Hi Mauro,
you can use owplMessageSend in place of phLineSendMessage
An'd i'm willing to accetp a patch reinstatit phLineSetFollowMe
into phapi-old.c
Thanks
Vadim
Mauro Sergio Ferreira Brasil wrote:
Hi Vadim!
During my efforts to migrate our codes to "qutecom-2-2-RC3"
version, I found two missing methods that we used on prior
versions that are: "phLineSendMessage" and "phLineSetFollowMe".
- "phLineSendMessage" is present on current codes, but is not
being defined. It's between "if 0" and "endif" statements and
with a "// not used" comment.
- "phLineSetFollowMe", by the other hand, disappeared from
current codes.
Is there any replacement for those methods ?
Thanks and best regards,
Mauro.
Vadim Lebedev escreveu:
Hi Mauro,
Le 6 mai 09 à 20:09, Mauro Sergio Ferreira Brasil a écrit :
Hello there!
Vadim,
Some time ago, when I was submiting a patch to this list, I
told you that we worked with old versions of the voip libs
that we've got from OpenWengo project and you've asked me why
we weren't using the new version still.
That's it, now we are migrating to new and updated codes
("qutecom-2-2-RC3" version to be more especific) and I would
like to ask some questions to you:
1- Despite of the existence of old methods "phXXX" (phInit,
phAcceptCall, etc) on libraries, I've noticed on entire
"sipwrapper" library (that I suppose is used on QuteCom) the
usage of the new "owplXXX" methods. So, I suppose the use of
those new "owplXXX" methods and associated new callback and
constants should be preferable, right ?
Yes...
2- The worst part of this migration probably will be to
identificate all changes introduced by prior programmers on
original code (which are highlighted) and apply those that are
really necessary. Any of these changes that prove to be still
necessary will be posted as patches to this list. Are you ok
with that ?
Sure...
More than everything I need some guidance on question 1.
With this migration done I should get back to the patch
regarding "mode" parameter from "fmtp" attribute negotiation
for iLBC codec.
Thanks and best regards,
Thanks a lot for your effort
Vadim
--
At.,
<CMMI_2.jpg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572
--
At.,
<mime-attachment.jpeg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572
--
At.,
<mime-attachment.jpeg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572
--
At.,
<mime-attachment.jpeg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572
--
At.,
<CMMI_2.jpg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572 diff -r b9d37dbd4b26 wifo/eXosip/include/eXosip/
eXosip.h
--- a/wifo/eXosip/include/eXosip/eXosip.h Mon May 25 11:54:53 2009
+0200
+++ b/wifo/eXosip/include/eXosip/eXosip.h Tue Jun 09 16:32:13 2009
-0300
@@ -446,7 +446,7 @@
* @param jid dialog id of call.
* @param status Status code to use.
*/
-int eXosip_answer_call (int jid, int status, char
*local_sdp_port, char *local_video_port, char *public_sdp_port, char
*public_video_port);
+int eXosip_answer_call (int jid, int status, char
*local_sdp_port, char *local_video_port, char *public_sdp_port, char
*public_video_port, char* answer_contact);
/**
* Answer call.
diff -r b9d37dbd4b26 wifo/eXosip/src/eXosip.c
--- a/wifo/eXosip/src/eXosip.c Mon May 25 11:54:53 2009 +0200
+++ b/wifo/eXosip/src/eXosip.c Tue Jun 09 16:32:13 2009 -0300
@@ -1504,7 +1504,7 @@
return 0;
}
-int eXosip_answer_call(int jid, int status, char *local_sdp_port,
char *local_video_port, char *public_sdp_port, char
*public_video_port )
+int eXosip_answer_call(int jid, int status, char *local_sdp_port,
char *local_video_port, char *public_sdp_port, char
*public_video_port, char* answer_contact )
{
int i = -1;
eXosip_dialog_t *jd = NULL;
@@ -1522,7 +1522,11 @@
return -1;
}
- if
+ if ( (answer_contact != NULL) && (answer_contact[0] != '\0') )
+ {
+ osip_strncpy(contact, answer_contact, sizeof(contact) - 1);
+ }
+ else if
(
owsip_account_contact_get
(
@@ -2651,7 +2655,7 @@
if (tr!=NULL && tr->last_response!=NULL &&
MSG_IS_STATUS_1XX(tr->last_response))
{ /* answer with 603 */
- i = eXosip_answer_call(jid, 603, 0, 0, 0, 0);
+ i = eXosip_answer_call(jid, 603, 0, 0, 0, 0, NULL);
return i;
}
}
diff -r b9d37dbd4b26 wifo/phapi/phapi-old.c
--- a/wifo/phapi/phapi-old.c Mon May 25 11:54:53 2009 +0200
+++ b/wifo/phapi/phapi-old.c Tue Jun 09 16:32:13 2009 -0300
@@ -1235,7 +1235,7 @@
eXosip_lock();
DBG_SIP_NEGO("NO STUN ports (a.local=%s, a.public=%s) (v.local=
%s, v.public=%s)\n",local_voice_port,0,local_video_port,0);
- i = eXosip_answer_call(ca->did, 200, local_voice_port,
optional(local_video_port), 0, 0);
+ i = eXosip_answer_call(ca->did, 200, local_voice_port,
optional(local_video_port), 0, 0, NULL);
if (i == 0)
{
@@ -1293,15 +1293,22 @@
int
+ph_answer_request_with_contact(int did, int reason, char*
answer_contact)
+{
+ int i;
+
+ eXosip_lock();
+ i = eXosip_answer_call(did, reason, 0, 0, 0, 0, answer_contact);
+ eXosip_unlock();
+
+ return i;
+}
+
+
+int
ph_answer_request(int did, int reason)
{
- int i;
-
- eXosip_lock();
- i = eXosip_answer_call(did, reason, 0, 0, 0, 0);
- eXosip_unlock();
-
- return i;
+ return ph_answer_request_with_contact(did, reason, NULL);
}
@@ -1666,6 +1673,33 @@
return i;
}
+
+
+int
+phLineSetFollowMe(int vlid, const char *uri)
+{
+ phVLine *vl = ph_valid_vlid(vlid);
+
+ if (!vl)
+ {
+ return -PH_BADVLID;
+ }
+
+ if (ph_find_matching_vline(uri, PHM_IGNORE_PORT))
+ {
+ return -PH_REDIRLOOP;
+ }
+
+ if (vl->followme)
+ {
+ osip_free(vl->followme);
+ }
+
+ vl->followme = osip_strdup(uri);
+
+ return 0;
+}
+
int
phLineSetBusy(int vlid, int busyFlag)
@@ -2922,7 +2956,7 @@
if (ph_follow_me_addr[0])
{
- ph_answer_request(je->did, 302, ph_follow_me_addr);
+ ph_answer_request_with_contact(je->did, 302, ph_follow_me_addr);
return;
}
#endif /* not used */
@@ -2969,13 +3003,11 @@
}
}
-#if 0 /* not used */
if (vl->followme && vl->followme[0])
{
- ph_answer_request(je->did, 302, vl->followme);
- return;
- }
-#endif /* not used */
+ ph_answer_request_with_contact(je->did, 302, vl->followme);
+ return;
+ }
ca = ph_locate_call(je, 1);
@@ -4932,7 +4964,7 @@
}
eXosip_lock();
- i = eXosip_answer_call(ca->did, 486, 0, 0, 0, 0);
+ i = eXosip_answer_call(ca->did, 486, 0, 0, 0, 0, NULL);
eXosip_unlock();
DBG_SIP_NEGO("release calls");
@@ -4974,13 +5006,11 @@
return FALSE;
}
-#if 0 /* not used */
if (vl->followme && vl->followme[0])
{
- ph_answer_request(did, 302, vl->followme);
- return FALSE;
- }
-#endif /* not used */
+ ph_answer_request_with_contact(did, 302, vl->followme);
+ return FALSE;
+ }
// ca = ph_locate_call(je, 1);
if((ca = ph_locate_call_by_cid(cid)) == NULL)
diff -r b9d37dbd4b26 wifo/phapi/phvline.c
--- a/wifo/phapi/phvline.c Mon May 25 11:54:53 2009 +0200
+++ b/wifo/phapi/phvline.c Tue Jun 09 16:32:13 2009 -0300
@@ -91,6 +91,8 @@
if (vl->used)
{
vl->used = 0;
+ if (vl->followme)
+ osip_free(vl->followme);
}
}
diff -r b9d37dbd4b26 wifo/phapi/phvline.h
--- a/wifo/phapi/phvline.h Mon May 25 11:54:53 2009 +0200
+++ b/wifo/phapi/phvline.h Tue Jun 09 16:32:13 2009 -0300
@@ -38,6 +38,7 @@
void * configurationHookUserData ;
OWPL_LINESTATE_EVENT LineState ;
int busy ;
+ char *followme;
/* sip parameters */
OWSIPAccount sipAccount ;
