Sigrid,
The request within dialog, at the sender's UA, *becomes* a request outside
dialog at the receiver i.e. your UA. RFC 3261 does suggest that it is up to the
implementer to choose whether he/she wants such a feature (i.e dialog recovery
after crashes, lock-ups, routing through constipated proxies etc). Only *a few*
of the possible requirements for dialog recovery are *suggested* there. IMHO,
it is perfectly *okay* for the receiving UA to reject the request with a 481.
As an simple example, let us suppose that your UA locks-up upon receiving a
re-INVITE (which it shouldn't do in the first place), re-starts and thereafter
receives an INVITE with both tags. AFAIK, most UAs will reject this request
with a 481.
Also, you cannot just start a dialog on receiving any INVITE with both tags!
You may need some form of database mechanism to cache the dialog information
including state so that you can match the re-INVITE(s) and recover the failed
dialog(s). Additionally, AFAIK, dialog recovery logic is usually implemented at
call servers! :D
Regards,
Jerry
> ----- Original Message -----
> From: "Sigrid Thijs" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Friday, November 18, 2005 10:10 PM
> Subject: Re: [Sip-implementors] To-Tag in INVITE request
>
>
> > Thanks for all your responses.
> >
> > The problem is that our UA is being tested for etsi conformance, and one
> > of the test-cases (SIP_CC_TE_CE_V_016) has the following purpose:
> > "Ensure that the IUT on receipt of an INVITE request with a TAG set on
> > the To header, sends a Success (200 OK) or a provisional (101-199)
> > response including the same URI and the same TAG for the To header."
> >
> > In this case our UA responds with 481 response (with correct to-tag) as
> > defined in section 12.2.2.
> >
> > From the etsi mailing list, I received the following answer:
> > "the test cases concerns an Invite request and thus is outside of a
> > dialog! The clause 12.2.2 is only valid after completion of the INVITE
> > request, and so having received the final answer. Being the initial
> > request the Test is than outside of dialog and 12.2.2 does not apply."
> >
> > Reading section 8.1.1.2 of RFC3261 I came across the following:
> > "A request outside of a dialog MUST NOT contain a To tag; the tag in the
> > To field of a request identifies the peer of the dialog. Since no
> > dialog is established, no tag is present."
> >
> > So I suppose the test-case is wrong.
> >
> > kind regards,
> > Sigrid Thijs
> >
> > Daniel-Constantin Mierla wrote:
> > > On 11/18/05 13:37, Sigrid Thijs wrote:
> > >
> > >> Hi,
> > >>
> > >> when a UA receives an INVITE request with a to-tag it should check if
> > >> there's a dialog that matches the request. But what if there's no
> > >> matching dialog? Should the UA treat it as an in-dialog request and
> > >> respond with an 481 (call leg/transaction does not exist) response.
> > >
> > > if the To tag is not recognized by the UA, it must respond with 481. If
> > > the To tag is recognized, the UA may try to restore the dialog. This can
> > > be the case of a re-INVITE received after UA crashed (See section 12.2.2
> > > from rfc3261).
> > >
> > >> Or should the UA treat it as an out-of-dialog request, create a dialog
> > >> and respond with 1xx reponses?
> > >
> > > No.Presence of To-tag means that the request is within a dialog.
> > >
> > > Daniel
> > >
> > >>
> > >> Kind regards,
> > >> Sigrid Thijs
> > >> _______________________________________________
> > >> Sip-implementors mailing list
> > >> [email protected]
> > >> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > >>
> > >
> > >
> >
> >
> >
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
