[SIPForum-discussion] Passing several 2xx responses to servertransaction

[Tomasz Zieleniewski]

Hi again,

Well in this case this more an implementation specific question.
You must keep in mind that in INVITE transaction if the response is 200 OK
then ACK is not considered part of the INVITE transaction and that is why
transaction passes into terminated state.
Because of the importance of delivering 200 OK response,
it is periodically passed directly to the transport and sent until ACK
arrives.
If there is finally no ACK session is considered confirmed by should be
immediately
terminated with BYE.

Proxy and UAC behavior with 200 OK response is different and
this is the reason why it is not handled in the transaction layer.
UAC just retransmitts ACK, proxy whenever it's transport layer receives a
responses
and there is no matching to a client transaction, passes responses directly
to the core
this case a proxy core. After that proxy core forwards response upstream
towards UAC statelessly.

Kind regards,
Tomasz


2009/5/2 Yevgen Krapiva <ykrapiva at gmail.com>

> Thanks for reply.
> But actually, I was asking about how to send more than one 2xx
> response over single
> invite server transaction ? The diagram of INVITE server transaction
> shows that once you sent 2XX response, the transaction goes into
> terminated state.
> This means, as I understand, that if I (proxy) need to say UAC that
> there is another one 2XX response, I need to send this one
> statelessly, beacuse initial server transaction is already terminated.
>
> Am I right ?
>
> 2009/5/2, Giscard Fernandes Faria <GISCARDF at nec.com.br>:
> > YKrapiva,
> >
> > Once a request is forked by a proxy, more than one response will be
> > received for the same request. However the UAC is not the one whom
> > receive all those
> > responses; the Proxy whom forked the request will receive them.
> >
> > What SIP RFC stands, is that those responses shall be merged in a unique
> > one
> > for non-INVITE request (the best response of all shall be picked).
> > However
> > when the request was an INVITE all responses shall be delivered to main
> > UAC;
> > this is necessary so UAC can open a distinct dialog for each 2XX
> > response or
> > event kill early dialogs for each 4xx-6xx response
> >
> > Hope this can help.
> >
> > Regards
> >
> >
> >
> > Giscard Fernandes Faria-  Software Engineering Department
> > NEC Brasil S.A.
> > Phone +55 11 2166-2713 * Mobile + 55 11 8561-0710
> > "There are no 'cookbook' methods that can replace intelligence,
> > experience, and good taste in design and programming", Bjarne Stroustrup
> > giscardf at nec.com.br
> >
> >
> > -----Mensagem original-----
> > De: discussion-bounces at sipforum.org
> > [mailto:discussion-bounces at sipforum.org] Em nome de Yevgen Krapiva
> > Enviada em: sexta-feira, 1 de maio de 2009 10:30
> > Para: discussion at sipforum.org
> > Assunto: [SIPForum-discussion] Passing several 2xx responses to
> > servertransaction
> >
> > Hi.
> >
> > I need clarification on the following quote from RFC 3261, Response
> > processing in statefull proxies:
> >
> >>Step 5. Check response for forwarding
> >>...
> >>This step, combined with the next, ensures that a stateful
> >>proxy will forward exactly one final response to a non-INVITE
> >>request, and either exactly one non-2xx response or one or more
> >>2xx responses to an INVITE request.
> >
> > How can I pass several responses over single server transaction ?
> > If I pass only one then transaction state will be changed to terminated.
> > _______________________________________________
> > This is the SIP Forum discussion mailing list
> > TO UNSUBSCRIBE, or edit your delivery options, please visit
> > http://sipforum.org/mailman/listinfo/discussion
> > Post to the list at discussion at sipforum.org
> >
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20090504/c3bb7663/attachment-0002.html>