Yes, there's some issue there, esp, if the server transaction has terminated with 2xx response, but another retransmission of ini-INVITE arrives then , it would be Thought as a new ini-INVITE, since transaction has ended its life.
This is why draft-sparks-sip-invfix comes into being, check it out. Besides that, since RFC3261 requires call-id and from tag creation should be *unique*, so this would not be a big issue in real world. -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 5:54 PM To: Rockson Li (zhengyli); [EMAIL PROTECTED]; [email protected] Subject: RE: [Sip-implementors] Re-invite without To Tag Yes, but is there any problem that the invite carrys the same call-id and from tag to the existing dialog, although the To tag is absent and it can be regared as an out-of-dialog request. Alex Zhang ESN: 6-554-8782 -----Original Message----- From: Rockson Li (zhengyli) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 5:35 PM To: Alex Zhang (GDNTRND); [EMAIL PROTECTED]; [email protected] Subject: RE: [Sip-implementors] Re-invite without To Tag Yes, when Core gets this "reinvite" , it just constructs the call identifier (call-id + from tag+to tag), and search if there's any existing dialog matched, If yes, it's a mid-dialog req,otherwise, it's a out-of-dialog req. So this so called "reinvite" might be a out-of-dialog req for Core. -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 5:25 PM To: Rockson Li (zhengyli); [EMAIL PROTECTED]; [email protected] Subject: RE: [Sip-implementors] Re-invite without To Tag But the re-invite is not mapped to the same transaction of the original Invite. It has a new transaction. Alex Zhang ESN: 6-554-8782 -----Original Message----- From: Rockson Li (zhengyli) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 4:58 PM To: [EMAIL PROTECTED]; Alex Zhang (GDNTRND); [email protected] Subject: RE: [Sip-implementors] Re-invite without To Tag I don't think so, This request should be handled by core. RFC3261 Sec 18.2.1 Next, the server transport attempts to match the request to a server transaction. It does so using the matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed to that transaction for processing. *** If no match is found, the request is passed to the core***, which may decide to construct a new server transaction for that request. -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 4:26 PM To: [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] Re-invite without To Tag It should be done at the Transaction Layer. One should not be sending such an invalid re-INVITE to the application, increasing the overhead on the application. Thanks, Bharat -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 1:16 PM To: [email protected] Subject: [Sip-implementors] Re-invite without To Tag Hi All, The re-invite should be processed, by UAS, as the request within the dialog. In this point, the re-invite without the To tag should be discarded, right? While, here is a problem, should it done by the Transaction layer which is responsible for the dialog state to detect such a invlid re-invite, or by the transaction user, i.e, the application user of the SIP stack? In other word, should a re-usable SIP Stack software be capabable of detecting a re-invite without To-tag? Thanks, Alex Zhang GSM/UMTS Voice Core - MSC Design Guangdong Nortel (GDNT) R&D Center PSTN: +86 020 89188782 / ESN: 6 554 8782 E-Mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> / YahooIM: zcc_nuaa " Stay Hungry, Stay Foolish." - Steve Jobs _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Please do not print this email unless it is absolutely necessary. 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 proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
