P.J. Cast. schrieb:

The INVITE transaction is terminated with 302 as this is a final
response. If the SIP UAC decides to try to reach the callee under the
provided contact then this is a new session, thus, a new transaction.
Thus, IMO the callid should change.

regards
klaus

On 1/8/08, P.J. Cast. pjcast@yahoo.com wrote:

Currently we can only create a new call, using the URI in the Contact header
of 3xx response as the destination of the call. So yes, the Call-ID will
change for the new call. I don't think this is a major issue, CMIIW.

To make this work correctly, I need to be able to get

No, this feature is not there, as you can't create a new, initial INVITE
when the previous initial INVITE failed (with pjsip, that is). But do tell
me if you absolutely need this feature, then maybe we can discuss possible
solutions.

cheers,
-benny

Thanks a bunch.

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.

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.

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
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.

Thanks

--- Benny Prijono bennylp@pjsip.org wrote:

http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

http://lists.pjsip.org/mailman/listinfo/pjsip_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

P.J. Cast. wrote:

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.

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.

its pretty vital that you do not design your system by expecting all
clients act the same way.

IMO you should fix the handling in your proxy.

regards
klaus

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@pernau.at
wrote:

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

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@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@pjsip.org wrote:

https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-September.txt

=== message truncated ===>

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

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?

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@yahoo.com wrote:

https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-September.txt

=== message truncated ===

  ____________________________________________________________________________________

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

On 1/17/08, P.J. Cast. pjcast@yahoo.com wrote:

I think this deserves a longer explanation, so I've just created a wiki page
to explain this. You can start from
http://trac.pjsip.org/repos/wiki/FAQ#pjsip_event

cheers,
-benny

Thanks