A NOTE has been added to this issue. ====================================================================== https://bugtracker.iptel.org/view.php?id=35 ====================================================================== Reported By: abalashov Assigned To: ====================================================================== Project: SEMS Issue ID: 35 Category: applications Reproducibility: N/A Severity: feature Priority: normal Status: new ====================================================================== Date Submitted: 2010-04-27 14:14 CEST Last Modified: 2010-06-14 13:36 CEST ====================================================================== Summary: Add B2BUA app with support for SIP Session Timers (SSTs) Description: Per discussion on sip-router/SEMS mailing lists, I am direly in need of a B2BUA application that uses core/plug-in/session_timer.
SST reINVITEs are sent at a configurable interval, and if a response to them is not received within the RFC-dictated transaction timeout period (or whichever timer is applicable), both legs of the call should be BYE'd by SEMS. This is for signaling only, no media relay. ====================================================================== ---------------------------------------------------------------------- (0000020) abalashov (reporter) - 2010-04-27 14:16 https://bugtracker.iptel.org/view.php?id=35#c20 ---------------------------------------------------------------------- One issue that has come up in the mailing list discussions is whether such a B2BUA app needs to be aware of SDP offer/answer updates that arise in the normal course of the dialog from the endpoints and reproduce the updated SDP body when sending its SST re-INVITEs, as opposed to whether it is acceptable to send empty re-INVITEs for this purpose. I do not know the answer, either formally or practically. ---------------------------------------------------------------------- (0000021) stefan (manager) - 2010-04-27 14:18 https://bugtracker.iptel.org/view.php?id=35#c21 ---------------------------------------------------------------------- as I wrote in my previous mail, this is implemented with r1821. please check out this application and submit/post bugs you find there. ---------------------------------------------------------------------- (0000022) abalashov (reporter) - 2010-04-27 14:19 https://bugtracker.iptel.org/view.php?id=35#c22 ---------------------------------------------------------------------- Another issue that came up on mailing list per Stefan: "Another issue is what to do when re-INVITE fails, I think that this is not handled properly at the moment (it is just ignored, but should probably tear down both calls - that's the thing for, I guess)." For my intended application, this depends on definition of "fails." On timeout, yes absolutely. On negative final reply, I would say perhaps not. ---------------------------------------------------------------------- (0000023) abalashov (reporter) - 2010-04-27 14:20 https://bugtracker.iptel.org/view.php?id=35#c23 ---------------------------------------------------------------------- Stefan, thank you for the implementation. I checked out r1821 several days ago to take a look and thought it might be beneficial to open a ticket in support of this initiative. I know r1821 contains the SDP updates, but what I do not know is whether it is the "cleanest" way that introduces the least _potential_ interop problems. It seems to me in principle that all other things being equal, the ideal would be to send empty reINVITEs, but only if it is allowed by the protocol specifications and supported by most stacks. ---------------------------------------------------------------------- (0000024) stefan (manager) - 2010-04-27 14:24 https://bugtracker.iptel.org/view.php?id=35#c24 ---------------------------------------------------------------------- technically, it is the cleanest solution; per rfc everyone must support empty INVITEs, and is supported by most stacks today (even though SEMS does not yet, due to historical reasons, but i hear that this is being worked on) ---------------------------------------------------------------------- (0000025) abalashov (reporter) - 2010-04-27 14:29 https://bugtracker.iptel.org/view.php?id=35#c25 ---------------------------------------------------------------------- I see. Thanks for the clarification. Is there a Mantis ticket already open for this feature, or did I open the first one? If this is a duplicate, please delete it, otherwise I will be testing this in the next week or so aggressively and post feedback here. Thank you very much again! ---------------------------------------------------------------------- (0000029) stefan (manager) - 2010-04-28 13:17 https://bugtracker.iptel.org/view.php?id=35#c29 ---------------------------------------------------------------------- btw, at the very moment sst_b2b is broken in trunk (as of 1857), but the sst_b2b patch should also be working on 1.2.0. ---------------------------------------------------------------------- (0000037) abalashov (reporter) - 2010-05-12 21:53 https://bugtracker.iptel.org/view.php?id=35#c37 ---------------------------------------------------------------------- The sst_b2b app is not in the 1.2.0 tarball; are you saying that if I backport/copy sst_b2b to 1.2.0 it should work, but not in 1.2.1 or trunk? I have been taking sst_b2b apart extensively and have had some mixed results. I also have a question or two. My questions are from the perspective of a newbie to the C++ API and someone who is a bit rusty at C++, so please forgive me if they are narrowly conceived and unsophisticated. I've been testing with 1.2.1, since I am not sure what exactly is broken and figured safest thing to do is to use latest stable version, especially since there was some sort of session timer interval-related fix in 1.2.1. 1) It does not appear that the SSTB2BDialog::sendReinvite() or SSTB2BCalleeSession::sendReinvite() methods are actually called at any point, as the debug log messages in them are never printed, even if I add some to the top of the method to occur in any condition below. Are those methods supposed to be getting called? If not, why are they there? 2) Aside from authentication, why is it necessary to subclass AmB2BCalleeSession and implement SSTB2BCalleeSession? Most of the methods there appear to be pass-through/duplicates of the same ones as in SSTB2BDialog. Is use of UAC auth features the only reason? 3) Re-INVITE situation is definitely broken at the moment because the SDP sent by SEMS in the re-INVITEs is neither empty/nonexistent, nor conforming to last SDP body received from a given leg. For instance, here is last SDP sent in 200 OK to leg A in call A->B: v=0 o=- 3482682448 3482682462 IN IP4 63.135.171.164 s=- c=IN IP4 63.135.171.164 t=0 0 m=audio 37192 RTP/AVP 0 101 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - - And here is the SDP sent to leg A in the re-invite: v=0 o=sems 1578514925 2005726774 IN IP4 208.52.173.20 s=session c=IN IP4 208.52.173.20 t=0 0 m=audio 10002 RTP/AVP I think somewhat understandably this results in "488 Not Acceptable Here" on that leg, and nothing happens. However, I cannot find a way to override this behaviour or effectuate the use of last_otherleg_content_type or last_otherleg_body since the sendReinvite() method implementations in SSTB2B.cpp do not appear to be getting invoked. 4) The re-INVITEs are only being attempted to leg A, not leg B. However, I don't see any responses from leg B containing: Supported: timer or Session-Expires: xx suggesting that the endpoint on leg B does not support SSTs. Is this the reason why SEMS does not attempt to also send reinvites there, or because the implementation is presently limited to one leg? The reason I ask this question is that the initial INVITE from A also does not contain anything about timers, yet all the responses SEMS sends it contain the SST-related headers. SEMS does doctor the INVITE from A before passing it onto B to contain SST headers, but endpoint A never explicitly agrees to participate in this any more or any less than endpoint B does. Why does B not get a re-INVITE too? Do they happen sequentially, e.g. positive final response must first be received from A before the reinvite is also sent to B? Thanks a lot in advance! ---------------------------------------------------------------------- (0000038) abalashov (reporter) - 2010-05-12 22:21 https://bugtracker.iptel.org/view.php?id=35#c38 ---------------------------------------------------------------------- Same issue with the RTP (https://bugtracker.iptel.org/view.php?id=3) occurs when testing sst_b2b with 1.2.0. This SDP body is just not acceptable to the endpoint (in this case, Asterisk). ---------------------------------------------------------------------- (0000039) abalashov (reporter) - 2010-05-14 01:16 https://bugtracker.iptel.org/view.php?id=35#c39 ---------------------------------------------------------------------- I managed to make the reinvites work by changing the invocation of s->sendReinvite to have updateSDP set to 'false' in SessionTimer.cpp. Now there is no body at all, and this at least works for my testing. The problem, however, is that it still only reinvites leg A, not leg B. So, in theory, if leg B went away, SEMS would not know it (it's not in the media path). ---------------------------------------------------------------------- (0000040) stefan (manager) - 2010-05-17 18:09 https://bugtracker.iptel.org/view.php?id=35#c40 ---------------------------------------------------------------------- for 1.2, you need to apply the whole r1821 patch (svn merge -r 1820:1821 https://svn.berlios.de/svnroot/repos/sems/trunk/ .), or copy sst_b2b over and modify AmB2BSession.cpp/h. for testing with trunk branch, please use r1821 directly - reinvite ping pong is not updated to changes in sip message handling introduced later. ---------------------------------------------------------------------- (0000041) abalashov (reporter) - 2010-05-17 21:40 https://bugtracker.iptel.org/view.php?id=35#c41 ---------------------------------------------------------------------- When you say 1.2, do you mean 1.2.0, or 1.2.1, or both? I assume 1.2.0 only from your comment above, but ask for clarity. ---------------------------------------------------------------------- (0000042) abalashov (reporter) - 2010-05-17 22:24 https://bugtracker.iptel.org/view.php?id=35#c42 ---------------------------------------------------------------------- Just tested with trunk r1821. See attachment sst_b2b_r1821-20100517.pcap for some rather strange results. Call is initiated by PBX at 208.52.173.7 through proxy 208.52.173.18 which passes it to 208.52.173.20 (SEMS server) with RURI destination of 63.135.171.164, the terminating carrier. Proxy 208.52.173.18 inserts Record-Route header putting itself in the path of sequential requests. Initial one or two ping-pongs to both sides (sip:[email protected] by way of 208.52.173.18, and sip:[email protected]) seem fine. But take a look at what happens starting at packet 22. For some reason, SEMS starts sending two reinvites packets to the PSTN side of the call (to 63.135.171.164); they are distinct requests insofar as they have different CSeq values. First one has (correct) SDP body, the second one has no SDP body. Unsurprisingly, the second one is answered 491 Request Pending since the first transaction has not yet completed. This continues for the rest of the call. Also, on the PSTN-directed (to 63.135.171.164) reinvites, SEMS puts no user part in its Contact URI. I am not sure if this is a correct thing to do. ---------------------------------------------------------------------- (0000043) abalashov (reporter) - 2010-05-17 22:29 https://bugtracker.iptel.org/view.php?id=35#c43 ---------------------------------------------------------------------- Also, in same capture, it is not clear why ACKs sent by SEMS in response to 200 OK from the PBX side (208.52.173.7/18) get sent to 208.52.173.7 directly even though Record-Route was inserted by the proxy. These ACKs should be getting sent hop-by-hop to the proxy 208.52.173.18 with RURI of ACK sip:[email protected] in the same way as the reinvites thems.elves. Looking at the ACK further, for example packet 65, I believe SEMS is not handling Route/RR correctly. You will see there is a header in there under Contact which does not have a header name, only an acontextual value of <sip: 208.52.173.18;lr=on;tag=as5951bce9>. This is the value of the Route header of course, but mangled. This header is correct in the reinvite request itself. ---------------------------------------------------------------------- (0000044) abalashov (reporter) - 2010-05-17 22:50 https://bugtracker.iptel.org/view.php?id=35#c44 ---------------------------------------------------------------------- Also take a look at sst_b2b_r1821-20100517-withtimeout.pcap for an example of what happens when one of the endpoints (the PBX end, 208.52.173.7) goes away because I firewalled off SIP traffic to it. I am not sure if I understand the mechanics of SST imperfectly, but the results here seem odd. Last 200 OK from 208.52.173.7 before it goes away is packet 98. From then, starting at packet 106, INVITEs going to that leg get only "100 Trying" from proxy between PBX and SEMS and no final responses. This continues until proxy sends locally generated 408 at packet 114, and starting at packet 118, PSTN side's 200 OKs to last re-INVITE are ignored by SEMS systematically. Eventually, at packet 437, the PSTN side BYEs to SEMS. Ignore packets 132 & 133 - this is me manually hanging up from the PBX side since it is firewalled. Is this how the mechanics are supposed to work? ---------------------------------------------------------------------- (0000045) stefan (manager) - 2010-05-18 00:03 https://bugtracker.iptel.org/view.php?id=35#c45 ---------------------------------------------------------------------- re note 41: 1.2 branch, or 1.2.1, as it contains fix for session timer values ---------------------------------------------------------------------- (0000046) abalashov (reporter) - 2010-05-20 21:05 https://bugtracker.iptel.org/view.php?id=35#c46 ---------------------------------------------------------------------- Any progress on this? I am not asking to be a pest, nor because I have any illusion of being entitled to anything whatsoever on a free/open-source basis. Of course not. I also imagine that your schedule is dictated largely by your employers and principally their commercial interests, and secondarily any novel hacking on SEMS for fun. However, I need to make an important and time-sensitive decision about whether this concept will eventually work or whether I should pursue other options, so any kind of feedback would be really appreciated. ---------------------------------------------------------------------- (0000047) stefan (manager) - 2010-05-21 14:04 https://bugtracker.iptel.org/view.php?id=35#c47 ---------------------------------------------------------------------- this being an open source project, we can obviously not make any hard commitments about deadlines. nevertheless, i am very interested personally in pushing this forward, as well. I would propose to branch trunk on r1821, fix sst_b2b in the branch, and then later fix the reinvite handling in trunk. this has the advantage that it generates a patch which can be directly applied to 1.2 branch. in the r1821 version i see two issues 1. reinvites for SST are sent even though current invite transaction is already in progress, which happens in two cases a) when SST timer fires for refresh, in which case it should be simply ignored b) when an SDP comes from the other side, in that case it must be saved and the reinvite made when the current transaction is finished 2. stopping the call in case the reinvite fails following some implementation notes: 1. detecting the case 1 is when dlg.uac_trans contains INVITE transaction dlg.reinvite() should fail with a known return code. 1.a case - in session timer onTimeoutEvent - just ignore timer event, because a refresh is already in progress (earlier than the timer hit); 1.b case - reinvite fails when processing B2BMsgBody event; event should be saved and posted again when reply to invite received 2. is just a matter of detecting in onSipReply and calling appropriate event handlers ohpefully this should give some insight into the status and what needs to be done. ---------------------------------------------------------------------- (0000049) stefan (manager) - 2010-06-02 22:31 https://bugtracker.iptel.org/view.php?id=35#c49 ---------------------------------------------------------------------- 0000047 is implemented with some additional safeguards in sst_b2b branch: https://svn.berlios.de/svnroot/repos/sems/branches/sst_b2b see also commit log of r1954/1956 ---------------------------------------------------------------------- (0000050) abalashov (reporter) - 2010-06-06 07:52 https://bugtracker.iptel.org/view.php?id=35#c50 ---------------------------------------------------------------------- Question about this: > check failed re-INVITEs in B2B calls - tear down calls if 408 / 481 received" Are 408s locally generated? If not, what is done if there is simply no response from other side? ---------------------------------------------------------------------- (0000051) stefan (manager) - 2010-06-07 00:53 https://bugtracker.iptel.org/view.php?id=35#c51 ---------------------------------------------------------------------- re 000050 yes 408 is generated locally if no response recieved ---------------------------------------------------------------------- (0000052) abalashov (reporter) - 2010-06-07 12:36 https://bugtracker.iptel.org/view.php?id=35#c52 ---------------------------------------------------------------------- Re 0000049 - please see attached PCAP sst_b2b-r1861-20100606.pcap. After r1854/1856 the basic objective that motivated interest in this feature has been accomplished, I will definitely say. However, there remain some behaviours which I think are not necessarily incorrect but somewhat mysterious to me. In this capture is the same basic scenario as my previous captures - call is set up From: [email protected] via proxy 208.52.173.18 through sst_b2b B2BUA at 208.52.173.20 and through to PSTN gateway 63.135.171.164. After a while, I kill -9 both Asterisk on 208.52.173.7 and proxy on 208.52.173.18 to simulate the originating endpoint absolutely going away, not returning any responses, etc. 1) Starting at packet 26, reinvites are sent to both sides with only one end (PSTN gateway) replying successfully. However, for some reason the 200 OKs returned from that endpoint are not ACK'd, so they are transmitted; is this how the flow is supposed to work? 2) At packet 41 there remains at least one instance in which reinvites are sent despite existing pending transaction. That endpoint thinks it is pending, of course, because the previous 200 OKs are not ACK'd. --- Other than those two things, it seems to me that everything works great now. Thanks! ---------------------------------------------------------------------- (0000053) stefan (manager) - 2010-06-07 15:13 https://bugtracker.iptel.org/view.php?id=35#c53 ---------------------------------------------------------------------- re 1) an empty INVITE has been sent to GW, it responded with 200 OK + SDP offer. if everything works, we send this offer into the other leg, get the SDP answer there, and send the SDP answer in ACK. now, the other leg does not respond. what would be the desired behaviour in that case? send an ACK with the last SDP after half the INVITE transaction timer? re 2) can you send a log of such a call? (for later reference: sip_scenario line is sip_scenario.pl sst_b2b-r1861-20100606.pcap 208.52.173.18/PROXY:1 208.52.173.20/SST_B2B:2 63.135.171.164/PSTNGW:3 ) ---------------------------------------------------------------------- (0000054) ibc (reporter) - 2010-06-14 13:14 https://bugtracker.iptel.org/view.php?id=35#c54 ---------------------------------------------------------------------- For re1): UA1 ---- SEMS ---- UA2 - SEMS sends re-INVITE with no SDP to UA2. - UA2 replies 200 OK + SPD_1 offer. - SEMS sends a re-INVITE with SDP_1 offer to UA1. - UA1 doesn't respond. As per RFC 3261 this means that the dialog between UA1 and SEMS is considered broken and SEMS MUST send a BYE to UA1 (the BYE is 100% mandatory). - Then SEMS should send an ACK to UA2 with "any" SDP (maybe the last used) and inmediately (after some seconds to avoid race conditions) a BYE to terminate the call with UA2. IMHO this is the only solution. ---------------------------------------------------------------------- (0000055) stefan (manager) - 2010-06-14 13:36 https://bugtracker.iptel.org/view.php?id=35#c55 ---------------------------------------------------------------------- re 00000054: this is what is implemented now (sst_b2b branch). the problem is that by the time that the re-INVITE to UA1 times out, the INVITE transaction on UA2 already timed out (no ACK/SDP answer received). so you get a lot of timeouts/broken calls already on the other side, even though SEMS is still processing calls properly. otoh, before the INVITE transaction on UA1 side is timed out, you obviously don't know whether UA1 is going to respond. Issue History Date Modified Username Field Change ====================================================================== 2010-04-27 14:14 abalashov New Issue 2010-04-27 14:15 abalashov Issue Monitored: abalashov 2010-04-27 14:16 abalashov Note Added: 0000020 2010-04-27 14:18 stefan Note Added: 0000021 2010-04-27 14:19 abalashov Note Added: 0000022 2010-04-27 14:20 abalashov Note Added: 0000023 2010-04-27 14:24 stefan Note Added: 0000024 2010-04-27 14:29 abalashov Note Added: 0000025 2010-04-28 13:17 stefan Note Added: 0000029 2010-05-12 21:53 abalashov Note Added: 0000037 2010-05-12 22:21 abalashov Note Added: 0000038 2010-05-14 01:16 abalashov Note Added: 0000039 2010-05-17 18:09 stefan Note Added: 0000040 2010-05-17 21:40 abalashov Note Added: 0000041 2010-05-17 22:09 abalashov File Added: sst_b2b_r1821-20100517.pcap 2010-05-17 22:23 abalashov Note Added: 0000042 2010-05-17 22:24 abalashov Note Edited: 0000042 2010-05-17 22:29 abalashov Note Added: 0000043 2010-05-17 22:29 abalashov Note Edited: 0000043 2010-05-17 22:43 abalashov File Added: sst_b2b_r1821-20100517-withtimeout.pcap 2010-05-17 22:50 abalashov Note Added: 0000044 2010-05-18 00:03 stefan Note Added: 0000045 2010-05-20 21:05 abalashov Note Added: 0000046 2010-05-21 14:04 stefan Note Added: 0000047 2010-06-02 22:31 stefan Note Added: 0000049 2010-06-06 07:52 abalashov Note Added: 0000050 2010-06-06 23:33 abalashov File Added: sst_b2b-r1861-20100606.pcap 2010-06-07 00:53 stefan Note Added: 0000051 2010-06-07 12:36 abalashov Note Added: 0000052 2010-06-07 15:13 stefan Note Added: 0000053 2010-06-14 13:14 ibc Note Added: 0000054 2010-06-14 13:36 stefan Note Added: 0000055 ====================================================================== _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
