Subject: [Sip] RE: [Sip-implementors] About Invite Server transaction

From: "Dale Worley" <[email-masked]>
Date: Wed, 1 Jun 2005 10:00:23 -0400

> From: Markus Hofmann [mailto:[email-masked]]
>
> There is the same Call-ID, same from tag and CSeq number is
> the same. The UAS should be able to recognise that this is a
> retransmission and should send its last answer (200 OK).

*No*, the Call-Id, From-tag, and CSeq are *not* enough to detect
retransmission -- you have to check the branch-parameter of the top Via as
well.  Otherwise, if you have received two forks of the same INVITE (say),
you will think they are duplicates, when they are not -- each must be
responded to separately.

This is the *single most common error* we have found when testing SIP
phones.  In ordinary office situations, it can cause inexplicable
difficulties for the users.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Markus Hofmann" <[email-masked]>
Date: Wed, 01 Jun 2005 11:28:44 +0200

"Dale Worley" <[email-masked]> schrieb am 01.06.05 10:51:35:
> 
> > From: Anil Bollineni
> > 
> > Assume 100, 200 responses are sent from UAS to client, and
> > they are lost. Then INVITE is retransmitted to UAS. As soon 
> > as UAS send
> > 200 OK it destroys the server transaction. Per UAS, the 
> > dialog state is
> > already created after sending 200 response. If INVITE is passed to TU
> > from transport layer, then how this INVITE is been treated as
> > retransmission of INVITE, since the TU, will  not able to match any
> > existing dialog (since no to-tag in INVITE), and will it 
> > treat as a new
> > call. Is the assumption correct? Or where in RFC this scenario will be
> > treated.
> 
> I believe that the correct handling is that the transport layer will
> discover that it is a retransmission of the original INVITE because of the
> Via branch-parameter, etc.  So the transport layer will re-send its 200
> response, and not notify the TU.
> 
> Dale
> 
Yes, I think so too.

There is the same Call-ID, same from tag and CSeq number is the same. The UAS should be able to recognise that this is a retransmission and should send its last answer (200 OK).

Markus
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201