When I get INVITE from call leg 1 I need to modify Via and
Contact headers (my external IP address is different then the one
on the listening node) of the INVITE for call leg 2.
So I'm using eXosip_call_build_initial_invite to build invite
message and then I used osip_message_set_contact to change the IP
address but it didn't modify the message.
I tried with osip_message_fix_last_via_header but it didn't modify
I used osip_message_set_via but it added a new Via header which is
not what I want.
Any idea ?
On 9/7/18 4:04 PM, Aymeric Moizard
Le ven. 7 sept. 2018 à 13:05, Tsvetan Filev
a écrit :
Yes I have working answer now.
There is something I noticed in the wireshark trace:
The UDP packet that holds the OK response has wrong
Is there osip/eXosip function that can disable it ?
You don't have to mind about it. This is only related to
5.09.2018 12:19, Aymeric Moizard wrote:
You are using the wrong API to answer
The API you use is for request within
You need to use API for request
"outside calls": eXosip_message_send_answer
Le mer. 5 sept. 2018 à 10:58,
Tsvetan Filev <address@hidden
a écrit :
I'm getting EXOSIP_MESSAGE_NEW event for
But when I try to do this:
printf("Got OPTIONS send OK
to tid %d\n", p_evt.tid);
int l_ret = 0;
eXosip_call_send_answer (m_ctx, p_evt.tid,
response %d error %d (tid %d)\n",
p_sip_event, l_ret, p_evt.tid);
I get SIP Send response 200 error -6 (tid
-6 is OSIP_NOTFOUND
What could be wrong ?
4.09.2018 17:40, Aymeric Moizard wrote:
Of course! Any outgoing and any
incoming request are doable.
eXosip2 won't be able to handle
properly new dialog established
by other request than
I've never seen such request anyway!
Le mar. 4 sept. 2018
à 15:02, Tsvetan Filev <address@hidden
a écrit :
Can eXosip handle (receive) OPTIONS
6.08.2018 16:05, Aymeric Moizard
How can I detect what
exosip event message
belongs to what call leg
I can't use cid as it is
different for INVITE and
RINGING for example.
You must use cid
which remains the same for the
If this is not the
case, there is a bug. I doubt
any such issue exists in
3.08.2018 18:16, Aymeric