14 Jul
2006
14 Jul
'06
6:04 p.m.
Hi Andrew,
Augustin, Andrew (external) wrote:
Hello Daniel,
Thank you very much for your tips.
You are right. The ACK did not match the dialog - under this particular scenario there was
an inconsistency between the branch, to, and from tags.
Hello All,
I have further questions related to this topic and routing of 'locally generated'
ACKs...
- How does OpenSER distinguish between 'locally generated' and
'end-to-end' ACKs?
end-to-end ACKs are matched based on transaction matching against the
INVITE transaction (see the RFC for the transaction matching elements).
for hop-by-hop ACKs, additional info as top most via and RURI as
required to identically match the INVITE transaction.
- How does OpenSER know when a 'locally
generated' ACK closes the transaction (e.g. Decline reply) that it is involved in?
by matching the ACK against the INVITE transaction.
- Does openser allow the modification of the Route
header in a 'locally generated' ACK and usage of TM's t_relay method to relay
this ACK? Or is this prohibited so that only OpenSER is allowed to automatically route
locally generated ACKs?
hop-by-hop ACK routing is not based on Route - actually this requests
does not contain any Route hdr
regards,
bogdan
Best regards,
Andrew
-----Ursprüngliche Nachricht-----
Von: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
Gesendet: Mittwoch, 12. Juli 2006 16:32
An: Augustin, Andrew (external)
Cc: users(a)openser.org
Betreff: Re: [Users] Declined INVITE invokes multiple Decline's at Proxy
Hello,
seems that the ACK does not match the dialog, thus the decline reply is
retransmitted. The network trace (ngrep) will help to spot more.
Which of Proxy-1..3 is OpenSER and how the INVITE is routed? looking at
the reply path, A seems to talk directly with proxy 2, but it is not
right since the decline reply is sent back to A from Porxy 1. Or you
didn't presented the full trace?
Cheers,
Daniel
On 07/12/06 14:26, Augustin, Andrew (external) wrote:
Hello,
I am using openser v1.0.
I have a problem with the following SIP scenario with openser:
- A invites B to a call session, B declines the invitation
The message trace shown below is just part of the message trace
produced for the above scenario displaying message frames in sequence
F43, F44 ... through F64
Initially everything works as expected: INVITEs, Trying (100) and
Ringing 180 messages are routed correctly from A to B and from B to A
via the intermediate proxies (this is not shown below). While still
'Ringing', B decline's the call (sends a Decline message) message: F44
in trace below. This also initally routes OK.
But the call flow for this scenario is expected to terminate at
message: F55 once the 'Decline' has routed its way back from the
B-Party to the A-Party and a final 'ACK' is sent by the A-Party to the
previous proxy: Proxy-1.
But what actually occurs is that openser running on Proxy-1
automatically resends a 'Decline' at message F56 identical to the
'Decline' it first sent at message F46. This in turn prompts further
ACKs and 'Decline's until it finally times out at message F107 (not
shown below).
It appears that openser saves the original message and attempts to
retry/resend the 'Decline' message when prompted by an ACK. This
continues for several cycles with ACKs and Decline's being sent and
received around the system until a timeout occurs.
The above behaviour also occurs for the following scenario:
- A invites B to a call session, B responds with a Busy
Can you help me to:
- understand what is going on
- terminate what appears to be an open 'transaction' for the 'Decline'
and prevent further 'Decline's and ACKs being sent around the system.
Best regards,
Andrew
_______________________________________________
Users mailing list
Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users