Hi, >>How would the proposed "Media Before Answer" endpoint/gateway >>application affect the billing in your opinion? Would it change >>nything with the issues here below? > >If you wanted to bill on signaling, the billing nodes would need to be able to differentiate between the "early" session >and the "real" session. They might could do this by noting the initiator of the session if a "repalces" model or >"reinvite" model is used, or by adding a header field.
The differentiation is based on what comes before 200 OK, and what comes after. I am not sure how separate/replaced dialogs etc would help. I don't think early media as such is the problem, but (as others have also said) forking. And, to be precise: parallel forking. Two potential solutions: 1. Forbid parallel forking. - That is probably no problem when forking occurs "in the network", for example when a request is first forked to an anouncement server, and after that towards the called user. I believe serial forking is mostly used in such scenarios - and 199 helps to indicate when one forked leg is "finished" :) - That is probably a problem when a registrar forks, because it would take a long time before all of the called user's terminals would be given a chance to "ring". Once the registrar has tried all terminals the calling user has probably hang up... 2. Terminate forking already on 18x - When a forking proxy receives a 18x (with SDP) on one leg, it would terminate all other legs. That is very similar to Dean's proposal on sending 200 OK already for early media (but it would not affect charging models etc which are based on the assumption that 200 OK means that the user has answered). - The problem, as Dean said earlier, is of course that the one that the entity that first starts to send early media (and 18x) may not be the entity that would accept the call. But, since all other legs would be terminated, the only entity which can accept the call is the one who send 18x first. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
