Hello All ,
I don't think that's entirely correct.
The question here is , what should the UAS Core do if it receives an
invite retransmission after the invite transaction has been
destroyed(200 OK sent out). The problem is the dialog matching will also
fail in the core because the retransmitted invite will not have a to tag
,hence the core will treat it as a new request. One solution is to put
the INVITE transaction into a "WAIT" state after the 200 OK has been
sent instead of deleting it. This will handle retransmissions.
This has been discussed in the forume some times back.
See this thread ...
http://www1.ietf.org/mail-archive/web/sip/current/msg11471.html
Regards ,
Sayan
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mahipati
Deshpande
Sent: Wednesday, September 28, 2005 10:19 AM
To: [email protected]
Subject: Re: [Sip-implementors] Question about receiving of
re-transmission ofinvite at UAS
Hi Markus,
In section 18.2.1 (RFC 3261) mentioned that -- "... If a matching server
trasaction is found, the request is passed to that trasaction for
processing.
If no match is found, request is passed to the core.
which may decide to constrcut a new transaction for that request..."
So I think is -- This means core is responsible for creating trasaction.
so when retransmitted INVITE is received after destroying IST, INVITE
request is passed to core, not INVITE trasaction. Core is going to match
received request with existing dialog. CSeq of this received request is
less than remote sequence number of that dialog, so it is going to
reject the request with 500 (section 12.2.2) (...not going to ignore as
I told in my previous email)
Am I right?
Thanks,
--- Markus Hofmann <[EMAIL PROTECTED]> wrote:
Hello Mahipati,
I think you misunderstand the question. He was asking about a
retransmission of a INVITE.
In my opinion the transaction layer has no chance to recognize that a
retransmission of an INVITE was received. UAS must create an new
INVITE transaction and give the INVITE to the UA core. The UA core
must now recognize that the INVITE is a retransmission and must
retransmit the 200 OK. This INVITE server transaction will be
destroyed.
But my problem is, that I do not understand where the bug should be?
Greeting
Markus
Mahipati Deshpande <[EMAIL PROTECTED]> schrieb am 27.09.05
08:10:23:
>
> Hi,
> When a INVITE is received, TU is going to create trasaction. If
> INVITE matches existing trasaction
it
> is considered as re-invite. In your case, for TU, INVITE trasaction
> is still active( it is waiting
for
> ACK). so it is going to treat it as re-invite and ignore it. If
> suppose it had received ACK for 200
OK
> before retrasmitteed INVITE arrives, TU is going
to
> ignore it because CSeq does not follow the rules.
>
> Thanks,
> Mahipati Deshpande
>
> --- Richard Wu <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi all,
> > Supporse there are a UAC and a UAS. The UAS
receives
> > the an INVITE and
> > creates a IST. It responds with a 200 OK (IST directly goes to the
> > terminated state) and waits for an ACK. At this time, if a
> > re-transmission of invite is received (with the
same
> > branch param in the
> > top via header), what should the UAS do? create
a
> > new IST or ignore it?
> > If there is a solution, does it apply to the re-invite? Thanks in
> > advance
> >
> > Richard Wu
> > ASTRI
> >
> > This message (including any attachments) is for
the
> > named addressee(s)'s use only. It may contain sensitive,
> > confidential, private proprietary or legally privileged
> > information intended for a specific individual and purpose, and is
protected by
> > law. If you are not the intended recipient, please immediately
> > delete it and all copies of
it
> > from your system, destroy any hard copies of it and notify the
> > sender. Any use, disclosure,
copying,
> > or distribution of this message and/or any attachments is strictly
> > prohibited.
> >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
> >
>
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
>
>
> Mahipati Deshpande
>
>
>
>
__________________________________________________________
> Yahoo! India Matrimony: Find your partner now. Go
to http://yahoo.shaadi.com
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
>
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail:
http://f.web.de/?mc=021193
Mahipati Deshpande
Send instant messages to your online friends
http://in.messenger.yahoo.com
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Confidentiality Notice
The information contained in this electronic message and any attachments
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
[EMAIL PROTECTED] immediately
and destroy all copies of this message and any attachments.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
