22 Aug
2006
22 Aug
'06
7:35 p.m.
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