[#XECS-1575] SipConnection.cpp does not support Replacing an Early Dialog at the Originator

sipXecs

SipConnection.cpp does not support Replacing an Early Dialog at the Originator

Created: 2008-07-16 15:22 Updated: 2008-07-18 13:17

Component/s:

sipXcallLib

Affects Version/s:

None

Fix Version/s:

None

Original Estimate:	Unknown	Remaining Estimate:	Unknown	Time Spent:	Unknown
File Attachments:	1. trace(3).xml (79 kb) 2. trace.xml (79 kb)

Description

« Hide

When executing a call pick up of a ringing call, SipConnection::processInvite() receives an INVITE with a Replace header containing the early-flag (RFC 3891 - Section 7.1). The function checks if the connection has been established already, and if not, it ignores the Replaces header.

From cp/SipConnection.cpp

2398 : // Replaces is independent of REFER so
2399 : // do not assume there must be a Refer-To or Refer-By
2400 : // Assume the replaces call leg does not exist if the call left
2401 : // state state is not established. The latest RFC states that
2402 : // one cannot use replaces for an early dialog
2403 : if (doesReplaceCallLegExist &&
2404 : (replaceCallLegState != CONNECTION_ESTABLISHED))
2405 : {
2406 : doesReplaceCallLegExist = FALSE ;
2407 : }

Proposed Solution: If the connection is not established, check for the early-flag in the Replaces header. If present, do not set doesReplaceCallLegExist to FALSE.

Also, strict compare needs to be disabled (set to FALSE) when finding a matching Call Leg..

Currently in cp/SipConnection.cpp:

2269 : doesReplaceCallLegExist =
2270 : ((CpPeerCall*)mpCall)->getConnectionState(
2271 : replaceCallId.data(), replaceToTag.data(),
2272 : replaceFromTag.data(),
2273 : replaceCallLegState,
2274 : TRUE);

Note: This is mainly just code maintenance, I can't really think of any scenario where this bug will affect any current sipXecs services.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Dale R. Worley - 2008-07-17 13:26

Could you clarify your comments, especially in regard to what difference this makes operationally (as seen at the SIP layer)?

E.g., when a Replaces header has the early-only flag, then only early dialogs may match. (And those are early outgoing dialogs; early incoming dialogs may never match.) If an INVITE with Replaces cannot find a matching dialog, it must return a 481 error.

The current code appears to allow an INVITE-with-Replaces to be accepted as if it was an ordinary INVITE under certain circumstances (because lines 2400 et seq. follow the test that leads to 481 errors).

[ Permlink | « Hide ]

Arjun Nair - 2008-07-17 17:43

Here is an example scenario - http://interop.pingtel.com/#pickup -, where the first UA is based on sipX libs (e.g. sipXpark).

Right now this is the call flow from the sipX UA perspective.. (I have left out the NOTIFYs/200OK between UA2 and UA1)

SIPX UA ................................. UA 1 ................................ UA2
    ----------------INVITE-------------------->
    <---------------180-------------------------
    <-----------------------------------INVITE with REPLACES----------------
    -------------------------------481 Transaction does not Exisit ---------->
    <----------------------------------------------ACK----------------------------------

See: trace(3).xml (Users 1553 and 1552 are based on sipX libs)

HACK: Commenting out line 2406 and changing the strictCompare to FALSE in line 2274, solves the issue.
See: trace.xml

Currently:
- When SipConnection.cpp receives an INVITE with REPLACES, it does a strictCompare and sees if there are any matching confirmed dialogs. If so, it will replace the existing dialog with a new one based on the received INVITE

What we need:
- On receiving an INVITE with REPLACES matching a confirmed dialog, check to see if there is an early-flag in the REPLACES header. If so, reject the request with a 486 Busy Here.
- If the INVITE with REPLACES containing an early-flag matches an early dialog that was initiated from this UA, then replace the existing dialog with this new one. If the dialog was not initiated locally then reject the request with a 481 (Call/Transaction Does Not Exist)..