[OpenSIPS-Users] [OpenSIPS-Devel] Planning next release - Roadmap
Iñaki Baz Castillo
ibc at in.ilimit.es
Tue Aug 26 16:49:24 CEST 2008
El Tuesday 26 August 2008 16:42:44 Iñaki Baz Castillo escribió:
> El Tuesday 26 August 2008 16:30:55 Ovidiu Sas escribió:
> > This is a little bit tricky, because you need to keep tracking of the
> > cseq for the received and sent message (each OPTION will increase the
> > sent cseq number). Each in dialog request that will come from the far
> > end UAC will need to have the cseq altered to be in synch with the
> > previous sent OPTION.
> > It can be done, but it is more work. Sending OPTIONS from the dialog
> > module itself is quite easy. I implemented and tested that, but then
> > I got lazy in implementing the cseq mangling stuff.
>
> If a proxy changes the CSeq in a request it must also change it in the
> responses to the client.
>
> Also note the problem handling PRACK since a PRACK message is an in-dialog
> request containing CSeq and Rseq, and the reply must contain Cseq and RAck.
> Example:
>
> UAC --------> UAS
>
> INVITE --->
> Cseq: 10
>
> <-- 180
> CSeq: 10
> Require: 10res
> Rseq: 555
>
> PRACK --->
> Cseq: 11
> RAck: 555 10
>
>
> So IMHO it's not so easy to handle and modify it in a proxy. Also this
> seems to me more a B2BUA task.
Also take in mind the case in which the proxy does parallel forking and just
one of the branches requieres PRACK.
Then the UAC must create a new in-dialog PRACK (with CSeq+1) just for that
endpoint, so incrementing in one the local CSeq just for that early-dialog.
In case of parallel forking, does OpenSIPS mantain a dialog (early-dialog) for
each branch? If not, the proxy cannot manage the CSeq correctly.
--
Iñaki Baz Castillo
ibc at in.ilimit.es
More information about the Users
mailing list