You're saying that the B party sends out a 2xx to an INVITE it hasn't received yet?
B Ben Gatewood Streamdoor Ltd 020 7422 0400 07835 136 187 [EMAIL PROTECTED] -----Original Message----- From: George Lee [mailto:[EMAIL PROTECTED] Sent: 17 August 2004 10:45 To: Ben Gatewood Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Problem with an intial SIP INVITEservertransaction. It is very possible that because of large network latency, B received initial INVite msg after sending out 2xx rsp. I think a resonable work-round is that implements a robust matching algorithm with more criterion such as brahchid, from tag, to tag etc. George Lee China ----- Original Message ----- From: "Ben Gatewood" <[EMAIL PROTECTED]> To: "Roman Shpount" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, August 17, 2004 3:28 PM Subject: RE: [Sip-implementors] Problem with an intial SIP INVITEservertransaction. > Hey Roman, > > In your scenario, why does the A party re-transmit the initial INVITE? It has > received a final response from the B party so it should ACK the 2xx not re-transmit > the INVITE (IMHO). > > B > > Ben Gatewood > Streamdoor Ltd > 020 7422 0400 > 07835 136 187 > [EMAIL PROTECTED] > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Roman > Shpount > Sent: 17 August 2004 00:00 > To: [EMAIL PROTECTED] > Subject: [Sip-implementors] Problem with an intial SIP INVITE > servertransaction. > > > I run into the problem with handling of retransmitted SIP INVITE message based on > the RFC 3621. > > Imagine the following situation > > INVITE 1 > -----------------------> > 100 > <----------------------- > 2XX > <----------------------- > re-transmitted INVITE 1 > -----------------------> > > Based on RFC 3261, server INVITE transaction terminates as soon as 2XX response is > sent. This means that re-transmitted INVITE will be treated as a new transaction. > This INVITE message will not match the existing dialog, since its To tag is empty. > This means it will be treated as new dialog creating message and phone will treat > this message as a new call, which is clearly not intended. > > ___________________________________ > Roman Shpount, VP of Technology > aTelo, Inc. -- www.atelo.com > > > > > > > _______________________________________________ > 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 > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
