The RFC that was pasted was intentionally truncated i guess, because
right after that paragraph it says
If the UAS does send a
final response when reliable responses are still unacknowledged, it
SHOULD NOT continue to retransmit the unacknowledged reliable
provisional responses, but it MUST be prepared to process PRACK
requests for those outstanding responses.
They should have Okayed the PRACK.
On 01/24/2012 08:50 PM, Sven Evensen wrote:
Hi Joegen,
We got an answer from the Aastra people, here is the response
They means that this issue is a sipxes issue, the sip-dect works rfc
conform. Here you can see the comment
RFC 3262 page 5 tell:
The UAS MAY send a final response to the initial request before
having received PRACKs for all unacknowledged reliable provisional
responses, unless the final response is 2xx and any of the
unacknowledged reliable provisional responses contained a session
description. In that case, it MUST NOT send a final response until
those provisional responses are acknowledged.
Within the scenario we received by capture file, the SIP-DECT is
allowed to send 200 OK before a PRACK is received.
In this scenario the provisional response (180) did not include SDP.
Is the issue from sipX perspective that 200OK comes before PRACK? And
then sipXbridge is in a wrong state, waiting for 200OK and times out
after 45 seconds?
Are there any quick fixes, like increasing that timer or not starting
the timer. What happens if sipXbridge does not send the PRACK if 200OK
already received and not starting the timer?
I can make a sipxBridge patch if needed but would appreciate a pointer
to where this logic is in hte code.
Regards,
Sven
On Thu, Jan 19, 2012 at 2:08 AM, Joegen Baclor <[email protected]
<mailto:[email protected]>> wrote:
When sending compressed archives, please use standard format. .gz
.bz2 and .zip are fine. Most developers are in linux and doesn't
have a ready codec for the rar format.
Nevertheless, the issue is with PRACK. There seems to be a race
condition with aastra and PRACK. It sends out 180 ringing with
require 100rel but do not wait for PRACK before it sends out 200
ok. By the time Prack reaches it, the INVITE transaction is no
longer existing since it was already termianted by the 200 ok.
The aastra then responds with
----Local Host:10.10.21.254---- Port: 5060----
----Remote Host:10.10.20.98---- Port: 5060----
SIP/2.0 481 Call Leg/Transaction Does Not Exist\r
Via: SIP/2.0/UDP
10.10.21.254;branch=z9hG4bK-XX-0708SN3H5vgPjVTQbOneD_1omw\r
Via: SIP/2.0/UDP
10.10.21.254:5090;branch=z9hG4bKbe4d2ce9ba8a26fc3f61f07b480d85e93536\r
From: <sip:[email protected];user=phone>
<mailto:sip:[email protected];user=phone>;tag=51643105\r
To: <sip:[email protected]>
<mailto:sip:[email protected]>;tag=t-6614d043b394e971\r
Call-ID:
[email protected]\r
<mailto:[email protected]%5Cr>
CSeq: 2 PRACK\r
Server: Aastra SIP-DECT (SW-Version=2.1SP4)\r
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, REFER, NOTIFY, INFO,
MESSAGE, UPDATE, PRACK\r
Content-Length: 0\r
\r
Try disabling 100rel/PRACK in aastra and see if this solves your
issue.
On 01/19/2012 02:48 AM, Sven Evensen wrote:
Hi,
We have a scenario where incoming PSTN calls which are
transferred to an Aastra DECT phone disconnects after about 45
seconds (after transfer).
Scenario is:
- A is external
- B is any phone
- C is Astra DECT phone
- And only when "2 step" transfer is performed.
- Sometimes it does work
This is happening on both 4.0.4 and 4.4 sipX.
Anyone experienced anything similar??
Attached are log file and sip-viewer xml of a failing scenario
and a successful scenario.
Regards,
Sven
--
*Sven Evensen, Operations Consultant*
*OnRelay*
Elizabeth House │ 39 York Road, London SE1 7NQ, UK │ +44 (0) 207
902 8123 │ mailto:[email protected] │ www.onrelay.com
<http://www.onrelay.com/>
This electronic message transmission contains information from
OnRelay, Ltd., that may be confidential or privileged. The
information is intended solely for the recipient and use by any
other party is not authorised. If you are not the intended
recipient, be aware that any disclosure, copying, distribution or
use of the contents of this information or any attachment, is
prohibited. If you have received this electronic transmission in
error, please notify us immediately by electronic mail
([email protected] <mailto:[email protected]>) and delete this
message, along with any attachments, from your computer.
Registered in England No 04006093 ¦ Registered Office 1st Floor,
236 Gray's Inn Road, London WC1X 8HB
_______________________________________________
sipx-users mailing list
[email protected] <mailto:[email protected]>
List Archive:http://list.sipfoundry.org/archive/sipx-users/
--
*Sven Evensen, Operations Consultant*
*OnRelay*
Elizabeth House │ 39 York Road, London SE1 7NQ, UK │ +44 (0) 207 902
8123 │ mailto:[email protected] │ www.onrelay.com
<http://www.onrelay.com/>
This electronic message transmission contains information from
OnRelay, Ltd., that may be confidential or privileged. The information
is intended solely for the recipient and use by any other party is not
authorised. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this
information or any attachment, is prohibited. If you have received
this electronic transmission in error, please notify us immediately by
electronic mail ([email protected] <mailto:[email protected]>) and
delete this message, along with any attachments, from your computer.
Registered in England No 04006093 ¦ Registered Office 1st Floor, 236
Gray's Inn Road, London WC1X 8HB
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
