Benny, Thanks, that is really good news. I agree that relying on a behavior possibly not present in some Sip Implementations there could cause issues. However, the main thing is really that the behavior is the same in the majority of Sip Clients, and if pjsip gets this ability by letting the client app fiddle with the CallID when needed, that would be excellent. Thanks again. I'll keep an eye for this in Svn. - Phillip --- Benny Prijono <bennylp at pjsip.org> wrote: > 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 > === message truncated ===> _______________________________________________ > 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 > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
