[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