Thanks Gerry, now it's working by using a different
CSeq
Best regards,
Humberto
--- Gerry <spamcop(a)gmx.at> wrote:
Yes, it has to be considered a retransmission,
because "Call-ID" and
"CSeq" are the same.
I'd say that _after_ openser got the reply to the
request (the INVITE in
this case), it forgets about the finished
transaction and, because there
seems to be no backlog of such, it considers the
INVITE as a new one,
but actually you constructed a retransmission ;-)) .
Greets, Gerry.
H Quintana schrieb:
Hello,
I'm running OpenSER 1.1.0 in the server
xxx.yyy.91.231, I'm also testing a program as 3rd
party call control at xxx.yyy.91.230 that is
sending
"simultaneous" reINVITEs to the 2
parties involved
in
the call (10252052 and 10092010) through
OpenSER.
Both messages are accepted by the loose_route
function. OpenSER relays the 1st reINVITE (to
10092010) but the second reINVITE (to 10252052)
is
not relayed.
Is openSER considering the 2nd message as a
retransmission of the first reINVITE ?
I'm having the same behavior by setting
tm.ruri_matching to 1 and 0. The results are the
same
if I call from 10092010 to 10252052, or if I send
the
1st reINVITE to 10252052. The only way to make
it
work properly is sending the 2nd reInvite after
some
seconds.
There is something else that I must add to the
reINVITEs to allow OpenSER to differentiate them?
The OpenSER debug for the ReINVITEs is at
http://pastebin.com/773285
The reInvite to 10092010 is at
http://pastebin.com/773286
The reInvite to 10252052 is at
http://pastebin.com/773287
Thanks for any suggestion.
Regards,
Humberto
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around