--On 18 March 2004 23:46 +0530 Sushil Kumar Verma <[EMAIL PROTECTED]> wrote:
What if we dont have any gateway(or RTP Proxy) in between? Suppose a proxy who is also responsible for billing is the only entity between SIP UAs...
Well then my suggestions aren't going to work. But if this is the case then equally the parties can dial eachother by IP address (or through an alternate proxy) and get free calls. All this goes to show is SIP is a session control protocol, and not a billing protocol :-)
What is wrong if proxy/B2BUA sends OPTIONS to each party at regular interval and if 200 OK is not received , disconnect the call and stop billing? (Any way all SIP entity are suppose to support OPTIONS).
Nothing in particular - it is one of the (ab)uses of the SIP protocol I was talking about. But it doesn't do exactly what you want, in that it is heuristic in nature. Possible failure modes (assuming A and B are UAs, and P is the proxy) include:
a) P's connectivity to A (but not B) breaks, or breaks to both inbound to sip server only, but audio stream between participants is OK. P sends BYE/CANCEL to A and B in the middle of a perfectly good call.
b) P's connectivity to A and B is maintained, but the RTP connection between A and B dies (connectivity issues, NAT/firewall issues etc.), and so you carry on billing a broken call.
So you'll cope with the cable being pulled, but not every situation, and you will respond incorrectly to others.
The point I tried but failed to make about the Cisco media gateway is that it *is* a UA. If other UAs sent BYE/CANCEL after no media stream for (say) 10 seconds, this problem would be largely sorted at the UA end. OTOH If you have "nothing to do with" the media stream, perhaps you just view yourself as "billing for session initiation and continued presence of the SIP server throughout the call", in which case perhaps you don't care (from a billing point of view) whether the RTP/other media stream works at all - this again suggests having the UA's have responsibility to drop calls with defective media streams might be the way forward.
Alex _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
