I kinda agree with you both. :) I agree with Klaus, as RFC 3261 says: 8.1.3.4 Processing 3xx Responses ... It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example. So since it only recommends (it's not even a SHOULD), it's seems like a bad idea to design a feature based on the assumption that Call-ID stays the same upon redirection. On the other hand, I agree with P.J. that as a stack, pjsip should have the flexibility to control the Call-ID in a dialog, so I'm willing to implement this. It should be rather straightforward, just need to add a new function to create dialog with the additional call-id parameter, and propagate this function all the way to pjsua-lib level. I'll do this in the next few days, and for now I've just added this ticket: http://www.pjsip.org/trac/ticket/442. Flame me if I forget.. cheers, -benny On 1/8/08, P.J. Cast. <pjcast at yahoo.com> wrote: > > 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 > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080109/ab08ac49/attachment-0001.html
