The Call Session Control Functions implemented in OpenIMSCore are based on IPTEL's SIP Express Router,a wonderful SIP proxy I would recommend to anyone building a VoIP system.
Surely, you would want your Application Server to track the user status via SIP SUBSCRIBE command, right ?
According to this draft specification , all you need to do is specify Event header to value debug, and Accept header to value "application/debuginfo+xml" , and if all the security settings are in place, your Application Server should be processing incoming NOTIFY messages in no time , right ? Well , not quite .
Caveat : I have not done any verifications on other platforms , but it will certainly not work for OpenIMSCore, source code revision 608, and here is why.
I went along the way I envisaged my application (remember, I was going to use SUBSCRIBE request to receive NOTIFY messages on user status in the IMS network) , however it just did't work . SCSCF kept crashing every time after receiving a perfectly formatted SUBSCRIBE from my AS application through ISC interface !
WT..Hell?!
Some scscf.cfg fiddling and a couple of Wireshark sessions later, I've decided to look into the C code of the actual SCSCF implementation. I am not going to post the code here even though it is released under one of those GPL licences,(and you can get it freely from svn repositories of berlios.de) but it will suffice to say that the only SUBSCRIBE Event headers that are accepted are "reg" (for registration status), which is of no practical use to me as I can get user registation status via either UDR or PNR through the Sh interface . To further support my case, and to paraphrase a dear professor of mine from undergrad studies - if you don't trust me, take a look at the code and see for yourself :)
But wait, there's more ! Not only does this implementation not allow "debug" Event headers, it also limits the acceptable senders to the Proxy Call Session Control Function and the registered UE itself.
So there you go , if you are not going to modify the OpenIMSCore code yourself, with the release source code release revision 608 that I am using, you won't get much of ISC functionality, unless of course you are developing something other than an Application Server.
I would like to close this piece with a remark that I am in no way bashing/critizing the OpenIMSCore development team - I highly admire and value the work that people at Fraunhofer FOKUS have completed thus far, and respect the fact that they were kind to share this platform with the rest of us to play around. Their efforts to help everyone on their mailing lists are commendable as well.
If anyone else has had similar experiences on this or any other IMS platform, I would love to hear them, particularly the stories of the "dreaded" ISC interface.
Hi! Nice investigation, but what was an initial reason to use 'debug' event? In my opinion, it is not intended to be used to track user status. So you could use either 'reg' event or a general-purpose presence server
ReplyDeleteHello, thanks for yourfeedback.
ReplyDeleteThe initial reason for using the debug package was that I had wanted to get information on other SIP requests that the user generates, not just the registration status.
According to the draft specs I have referenced , this is what the debug event package is meant for.
If you are looking to get just the registration info, ppart from presence server or 'reg' event package, there is also the option to use the UDR DIAMETER command.
Ok, now I see. But I don't think that using 'debug' event is something related to ISC (btw, there is it referenced in 3GPP specifications?).
ReplyDeleteI suppose that iFC is the tool you have to provide AS with information about user-generated requests, isn't it appropriate here?
My app (AS) is not typical in that that it tracks user-generated requests in real-time. It's not a typical service AS. Therefore it has no use of iFC in providing what it does.
ReplyDeleteI have to look it up and see where exactly is the 'debug' event draft spec referenced - as you know 3GPP specs defining IMS as well as ISC are very extensive.
Thanks again for your feedback, and I would welcome and encourage you to share any experience you've had in developing ISC apps for OpenIMSCore.
Fairly speaking, I can't see why proxying all user-generated requests through your AS is not real-time enough - every SIP message from user A to user B will reach your application before it reaches B, thereby you could implement for example a list of A's active calls updated in a real-time
ReplyDeleteThat is exactly what my app does with the current implementation :)
ReplyDelete