Of course everything is easy to spoof. So nothing is trusted blindly. That is really beyond the point of this disscussion IMHO. In regards to clients that automatically redirect, I did not state that pjsip should automatically do it. It would be nice if there was a method to call to reinvite with the same callid would be nice. This archive, top two posts, illustrates what I would like: https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-September.txt I don't think either way is right or wrong, but it would be extremely nice if pjsip was able to coup with this. As, almost all phones I have used work by reusing the callid for a redirection. Ciscos, grandstreams, Resiprocate (iirc what xlite uses). As it stands, this is a pretty big hurdle right now for me, as supporting forwards in this manner is a must. I could possibly hack the heck out of pjsip to support this, but I would rather see a compromise that would become part of pjsip. Cheers --- Klaus Darilion <klaus.mailinglists at pernau.at> wrote: > P.J. Cast. wrote: > > Hi Benny, > > > > The issue is the sip proxy server expects the > CallID > > to be the same, so it can identify the forwarded > call > > as being part of the previous call. Else, it would > be > > a completely new transaction. > > Terminology: > transaction: consists of a request, optional 0..n > provisional > responses and a final response. > > Thus every new INVITE request is a new SIP > transaction. > Its even a new SIP dialog as the the first INVITE > transaction did not > created a dialog. > > Thus, the relationship between the first INVITE and > the second INVITE is > only at application layer - not at SIP layer. A good > SIP client should > not automatically accept a 302 and make a new call > but it should ask the > user if it wants to make a new call to the provided > URI. > > Maybe some clients reuse the call-id in the new call > attempt, but others > will not and IMO both is valid. > > A SIP proxy (or the billing system) should never > rely on data provided > by the SIP client. > > If you need full control over call setup and billing > it is better to do > the redirection in the proxy. > > do not trust user provided data (like call-id, tags, > contact ...) > blindly as this are very easy to spoof. > > > > > For instance, a UserA dials UserB, but UserB is > not > > available and he has setup a forward to some PSTN > > number. Consequently, Proxy returns 302 with new > > number. > > > > Now, with the callid, the proxy can recognize that > it > > was a forward from UserB, so UserB is the party > > responsible for it (and any billing/accounting > > associated). > > > > With a new CallID, UserA would have to pay to be > > forwarded. Not really optimal. > > Again: never expect all clients to act like you > expect them. If you want > to charge to call to user B then make the > redirection in the proxy. > > > > For reference, both Xlite & Grandstream SIP Phones > I > > have used send the Invite in response to the > callid > > with the same CallID to maintain the transaction. > > Though, they differ in how they send out the To > and > > Sip URI fields. > > > > It is pretty vital that this works by placing a > call > > with the same call id. Is there no way to control > > its pretty vital that you do not design your system > by expecting all > clients act the same way. > > > this? Perhaps it would be a simple matter to > modify > > pjsip? If so, where would you recommend > > modifications... allow client to set the callid > sounds > > simplest. > > IMO you should fix the handling in your proxy. > > regards > klaus > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
