[SIPForum-discussion] forwarding more than one 2xx in a proxy server

[Young-Geun Park]

RjS, 

             

I have understood your comments after I discriminated meaning difference
between transaction and TU.

I suppose that I confused for a while.

             

Thank you very much

 

Best regards, 

Park

 

 

-----Original Message-----
From: Robert Sparks [mailto:rjsparks at nostrum.com] 
Sent: Tuesday, February 06, 2007 12:43 AM
To: Young-Geun Park
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] forwarding more than one 2xx in a proxy
server

 

 

On Feb 2, 2007, at 9:42 PM, Young-Geun Park wrote:





             Thanks for you answer.

 

             For a proxy to forward the second and any subsequent 2xx
responses,

should it work in both stateful and stateless mode ?

 

anyway, while a proxy can forward the second and any subsequent 2xx
responses,

a UAC that sent the INVITE can not receive these responses subsequently

because the INVITE client transaction transition to 'terminated' already.

This is right?

No - the specification split transactions and transaction users (search for
"transaction users" and "cores").

The specification of the endpoints' UAC core behavior talks about handling
multiple 200s.

 

In a nutshell, the endpoint can end up in multiple dialogs (multiple calls)
by sending one INVITE.

It is local policy how it handles that.

 

Most things deal with it by treating the first 200 normally, and entering
whatever session it negotiated.

The 2nd and subsequent are ACKed, and then BYEs are sent on the dialogs they
create.

 



 

In that case the following service scenario is impossible. Is that right?

A UAC sends a INVITE that searches for any service to a proxy and want to
receive available all services.

The proxy will fork the INVITE to many targets(UAS) and several UASs return
a response that service is available.

Then the UAC receives those responses and then determine one service.

This is possible - the endpoint _could_ collect all the 200s (there are some
subtle things in determining how long to wait, and some other

not-so-subtle tradeoffs it would have to make with respect to media
clipping) and then choose the "best" one it likes.

 

It's also legal for it to enter into calls with every leg. This might make
more sense if the UAC is an automaton than if it were a phone being

used by a human.

 

RjS

 



 

Best regards,

Park

 

 

-----Original Message-----
From: Robert Sparks [mailto:rjsparks at nostrum.com] 
Sent: Saturday, February 03, 2007 12:39 AM
To: Young-Geun Park
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] forwarding more than one 2xx in a proxy
server

 

The text as written was intended to cause the proxy to forward the second
and any subsequent 2xx responses statelessly

(search for the word statelessly in that section).

 

MANY proxy implementors have written code that does the correct thing here
(if you are not sure what the correct thing

to do is, we can walk through it off-list). 

 

Now, I have to point out that there is a known bug with moving that
transition to terminated (see  <http://bugs.sipit.net/show_bug.cgi?id=769>
http://bugs.sipit.net/show_bug.cgi?id=769).

>From that bug report:

 

The current text in 3261 instructs a UAS to destroy an INVITE transaction
the

instant it sends a 200.

 

This has the unintended consequence that any retransmissions of the INVITE

request that arrive after that destruction will be treated as a new request.

 

This interacts both with endpoints and proxies (the deletion of the server

transaction combined with stateless forwarding of responses without matching

transactions provided forwarding of multiple 200s to forked INVITES).

 

The fix will involve having the server transaction continue to exist long

enough to drain any retransmissions of the INVITE and related changes to

the UAS handling of retransmitting the 200s, and proxies handling multiple

200s/stray responses.

 

RjS

 

On Feb 2, 2007, at 6:21 AM, Young-Geun Park wrote:

 

Hi, all

 

I don't know why it is possible.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070206/936d3f4c/attachment-0002.html>