Thanks Gary.

Here is example call flow.
                          B2B
UA1 <------------> UAS|UAC <--------------> UA2
|----------------- session established ------------|
|        re-INVITE         |                             |
|----------------------------->|                             |
|    error response      |                             |
|<-----------------------------|                             |
|                               |        re-INVITE       |
|                               |<-------------------------- |

As you see, there is pending request beween UA1 and UAS of B2B, but in
view of UA2, there is no pending request between UAC of B2B and UA2 .
It might be okay if B2B sends 491/500 to UA2 and then UA2 responses to
the final response with ACK.
But I think final error response should explain why the request was
rejected or failed. In view of UA2, if UA2 receives 491 from B2B, I
think UA2 doesn't know why B2B sent 491 although there is no pending
request in the dialog between UA2 and B2B.
As you said, I think 500 with Retry-After would be better than 491 in this case.

Thanks in advance.
Sumin.

On 10/11/06, Gary Cote <[EMAIL PROTECTED]> wrote:
>
>
> On 10/11/06, Sumin Seo <[EMAIL PROTECTED]> wrote:
> > 1. Do you mean that UA can't initate INVITE client transaction if
> > there is uncompleted or uncomfimed INVITE server transaction?
> > For example, if there is uncompleted or uncomfimed INVITE server
> > transaction, UA can't initiate re-INVITE for session timer request?
>
> That's correct. Have you read RFC 3261, Section 14.1? It's pretty clear.
>
> > 2. Even though B2B has INVITE server transaction related with UA1,
> > there is no pending transaction between B2B and UA2. What happen in
> > UA2 if B2B sends 491 although all previous INVITE transactions between
> > B2B and UA2 completed?
>
> Again, RFC 3261, Section 14.1 is pretty clear about how the UAS should react
> to the 491 Request Pending response. Which part didn't you understand?
>
> I guess an alternative to the 491 Request Pending response would be a 500
> Internal Server Error response, with a Retry-After header telling the UA
> when to try the re-INVITE again.
>
> - g
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to