Statistics
Reviews Started
today 0
previous week 0
previous month 0
Comment Volume
0 comments 0 defects
Defect Metrics
Open reviews
2 open reviews
2 peak
Open Review Age
2 Reviews
Reviews
Expand All |
Collapse All
Review
DEMO-9
Join/Replace Changes.
Summary of changes. ----------------- 1. RFC 3891 and 3911 are implemented. Session Targetting based on Join/Replace is implemented as per JSR 289. The changes are applicable only to UA and not to Proxy. 2. 3911: An incoming request to the server will contain Join header with the callid/fromtag/totag of the call it want to join. Sailfin will make sure that the session of the joining request is added to the SAS of the session specified by the Join Header. 3. 3891: Same as 2 except that the header is Repaces and not Join. Main difference is the ability to specify the early-flag. 4. Both RFCs talk about authentication requirements. My thinking is that with the current digest auth support, the requirements can be met by the application. 5. SipSessionsUtil.getCorrespondingSession is implemented. 6. SAS.getApplicationName is implemented (it was a simple change). 7. For 3911, the RFC explains how the original request will be terminated. My thinking is that the termination will be done by the application and not by the container. Thats the reason why 289 have the new SipSessionsUtil.getCorrespondingSession api. 8. The request coming in to the container with Join/Replace will not have fragment-id. So, to searching dialog is a problem. Would join/rep lace be applicable in case of spiralling? probably not. Let me know, if there is a way to introduce fid in Join/Replace requests. 10. I have added 5 devtests. FT seems to be fine.
Under Review
16 files 2 comments
DEMO-9 Join/Replace Changes. »
Summary of changes.
-----------------
1. RFC 3891 and 3911 are implemented. Session Targetting based on Join/Replace is implemented as per JSR 289. The changes are applicable
only to UA and not to Proxy.
2. 3911: An incoming request to the server will contain Join header with the callid/fromtag/totag of the call it want to join. Sailfin will make sure that the session of the joining request is added to the SAS of the session specified by the Join Header.
3. 3891: Same as 2 except that the header is Repaces and not Join. Main difference is the ability to specify the early-flag.
4. Both RFCs talk about authentication requirements. My thinking is that with the current digest auth support, the requirements can be met by the application.
5. SipSessionsUtil.getCorrespondingSession is implemented.
6. SAS.getApplicationName is implemented (it was a simple change).
7. For 3911, the RFC explains how the original request will be terminated. My thinking is that the termination will be done by the
application and not by the container. Thats the reason why 289 have the new SipSessionsUtil.getCorrespondingSession api.
8. The request coming in to the container with Join/Replace will not have fragment-id. So, to searching dialog is a problem. Would join/rep
lace be applicable in case of spiralling? probably not. Let me know, if there is a way to introduce fid in Join/Replace requests.
10. I have added 5 devtests. FT seems to be fine.
-----------------
1. RFC 3891 and 3911 are implemented. Session Targetting based on Join/Replace is implemented as per JSR 289. The changes are applicable
only to UA and not to Proxy.
2. 3911: An incoming request to the server will contain Join header with the callid/fromtag/totag of the call it want to join. Sailfin will make sure that the session of the joining request is added to the SAS of the session specified by the Join Header.
3. 3891: Same as 2 except that the header is Repaces and not Join. Main difference is the ability to specify the early-flag.
4. Both RFCs talk about authentication requirements. My thinking is that with the current digest auth support, the requirements can be met by the application.
5. SipSessionsUtil.getCorrespondingSession is implemented.
6. SAS.getApplicationName is implemented (it was a simple change).
7. For 3911, the RFC explains how the original request will be terminated. My thinking is that the termination will be done by the
application and not by the container. Thats the reason why 289 have the new SipSessionsUtil.getCorrespondingSession api.
8. The request coming in to the container with Join/Replace will not have fragment-id. So, to searching dialog is a problem. Would join/rep
lace be applicable in case of spiralling? probably not. Let me know, if there is a way to introduce fid in Join/Replace requests.
10. I have added 5 devtests. FT seems to be fine.
Binod PG, Bhavanishankar, torarnv.