inline Regards, Jeroen
----- Original Message ----- From: "Markus Hofmann" <[EMAIL PROTECTED]> To: "Paul Kyzivat" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Friday, October 06, 2006 11:30 AM Subject: Re: [Sip-implementors] BYE request overlapped on re-INVITE > Paul Kyzivat wrote: > > Hi Paul, > >> -- OR, this could be treated as a new invite within an existing dialog, >> and so be treated as a new call. (This is not a recommended behavior and >> clearly has a bad result here.) > > exactly that the point. Where should the UAS know that the Re-INVITE > retransmission belongs to an old dialog? The whole information is > destroyed after the BYE was answered with 200 OK. > The BYE ServerTransaction lingers for 64*T1 seconds (for UDP), i.e. Timer J. A properly implemented SIP stack would keep the dialog state around for at least that long, in order to avoid this situation > Another point is what is the goal to produce retransmission after > sending out after a BYE. What the UAC expects? Is it still necessary to > send out Re-INVITEs when the own call is gone? > > In my opinion the BYE should be give to the transaction layer until the > INVITE transaction was finished. > The transaction layer treats each transaction independently of others. Associations between transactions are made in the dialog layer, that would be the place to implement this. It already has to ensure that no new INVITE is sent while another one is pending; BYE can be added to that logic > Regards, > Markus > > > _______________________________________________ > 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
