[Serusers] dealing with parallel forking ...

[Cesc Santa]

tu saps pq ho pregunto, no? :)
estava jugant amb el teu modul ... i no m'envia els cancels ... pero
he de dir q l'he modificat una mica, no massa, de forma q retorna no
solament els contactes rebuts via multicast si no q tambe els
contactes locals q ha pogut resoldre ...
Els tests els faig de forma local ... sense rebre respostes del
multicast ... i el q fa el SER es un fork ... pero al rebre el segon
OK, no cancela la resta de branches ... dius q hauria de fer-ho
automaticament?

On 8/3/07, samuel <samu60 at gmail.com> wrote:
> inline...
>
> 2007/8/3, Olaf Bergmann <Olaf.Bergmann at freenet-ag.de>:
> > Cesc Santa wrote:
> >
> >
> > > I am doing some tests and it is not really a problem ... but maybe
> > > someone has a better idea. In my configuration, the first 200 OK
> > > received is forwarded to the caller and the whole SIP session setup
> > > (caller + 1st callee).
> > > Next 200 OKs are also delivered to the caller,
> >
> > That is the correct behavior of a SIP proxy.
>
> I think the proper forking behaviour is to send a CANCEL to all branches
> upon receiving a 200 from one of them and I think that SER does this
> automatically... isn't it??
>
>
> > > who happily ignores them ...
> >
> > That is broken behavior of a SIP UA.
>
> I think it's not specified what to do when a UA receives a second  200
> OK.... it can safely ignore it, it can present a mesage to the user, it can
> try to mix the different audio streams, it can create a second dialog and
> put the first on hold, and more options.
>
> Try to look at HERP and "early media and forking" topics....
>
>
> > > it is the task of the 2nd (and 3rd, ... ) callee to at a
> > > certain point give up and send a BYE, to which the caller replies with
> > > 481 no call leg ...
> > > It all works ... but, I wonder if ser could send CANCELs after
> > > receiving the 1st 200 OK ... if yes, how? :)
> >
> > No, you cannot CANCEL an INVITE after having received a final
> > response. This must be done by the caller after having sent the ACK.
> > The UAC you have used is broken. The callee's UA tries to deal with
> > it and does the best it can. You should use a standards-compliant
> > SIP UA for your tests.
>
> Hope I'm right though I think it should work "as it is"  ;)
>
> sam.
>