inline... --- Roman Shpount <[EMAIL PROTECTED]> wrote: > 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. > [Rao] Acc to RC3261 re-transmissions should be stopped after receiving 1xx. Sec 17.1.1.2 says "These retransmissions SHOULD only be done while the client transaction is in the "calling" state."
You may consider a work-around for this problem at the called party by identifying the dialog with Call-ID + from tag instead. This is very unreliable and not recomended by RFC. > ___________________________________ > 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 > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
