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?
- How does OpenSER know when a 'locally generated' ACK closes the transaction (e.g. Decline reply) that it is involved in?
- 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?
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@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
A-Party Proxy-1 Proxy-2 Proxy-3 B-Party 10.1.195.134:50 10.1.195.134:50 127.0.0.1:5070 127.0.0.1:5080 10.1.195.208:50 | | | | | |<nging 180 F43<| | | | | | | | | | |<----------------------------- Decline 603 F44<| | | | | | | |>F45 ACK ------------------------------------->| | | | | | | |>F46 603 Decline ------------->| | | | | | | | |<--------------------- ACK F47<| | | | | | | | | |<cline 603 F48<| | | | | | | | | |>F49 ACK ----->| | | | | | | | | |>F50 603 Decli>| | | | | | | | | |<----- ACK F51<| | | | | | | | |<------------- Decline 603 F52<| | | | | | | | |>F53 ACK --------------------->| | | | | | | |<cline 603 F54<| | | | | | | | | |>F55 ACK ----->| | | | | | | | | | |>F56 603 Decline ------------->| | | | | | | | |<--------------------- ACK F57<| | | | | | | |<cline 603 F58<| | | | | | | | | |>F59 ACK ----->| | | | | | | | | | |>F60 603 Decline ------------->| | | | | | | | |<--------------------- ACK F61<| | | | | | | |<cline 603 F62<| | | | | | | | | |>F63 ACK ----->| | | | | | | | | | |>F64 603 Decline ------------->| | | | | | |
--
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Augustin, Andrew (external) -
Bogdan-Andrei Iancu