Hi again, Well, I think I found a way to do this without relying on CallId changing... But, the ability to change CallID would still be nice, but is not urgent. However, how do i go about getting the contact header? >From the on_call_state callback, when state is disconnected, and last_status is 302, I check the remote_contact string of pjsua_call_info, but it contains only the original contact of the first few signaling messages, but not the new destination location. Am I doing something wrong? Is there another method I should be using to get access to fields (would probably help with receiving other custom headers)? I'll look through the doc's some more, but a quick hint would be awesome ;-) Thanks --- "P.J. Cast." <pjcast at yahoo.com> wrote: > 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. > === message truncated === ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
