[Users] BYE before 200 OK?

[Michael Ulitskiy]

Initially I just grepped sip capture log by callid, but after you said
that I also checked From and To tags and they're the same.
So I guess I need to complain.
Thanks for the clarification.

Michael


On Friday 02 September 2005 02:17 pm, Bogdan-Andrei Iancu wrote:
> Hi there,
> 
> Iqbal wrote:
> 
> > no BYE should occur, after 200 OK, your UAC should send ACK to 
> > openser, and openser  ACK to gateway, it seems as if the pstn GW is 
> > not getting the ACK's
> >
> > Iqbal
> >
> > Michael Ulitskiy wrote:
> >
> >> Hello,
> >>
> >> Can someone please enlighten me on if this is allowed to send BYE
> >> before 200 OK? I thought that BYE should be used only after dialog
> >> established, but now I have a SIP PSTN termination provider and they
> >> appear to be sending BYE with route headers right after 183 Session 
> >> Progress
> >> in some cases.
> >> So the session looks like the following:
> >> UAC                                OpenSER PSTN                       
> >> Provider UAS
> >> INVITE to openser
> >>                                         180 Trying back to UAC
> >>                                         INVITE to UAS
> >>                                                                                                
> >> 180 Trying back to openser
> >>                                                                                                
> >> 183 Session progress back to openser
> >>                                       183 Session Progress back to UAC
> >>                                                                                                
> >> BYE to openser with Route headers
> >>                                       BYE to UAC (loose_routing)
> >> 200 OK to openser
> >>                                       200 OK to UAS
> >> Is it ok?
> >
> No this is not OK - BYE must be use only if the call was established via 
> a 200 OK. If UAC want to terminate the call before the 200 OK, it must 
> use CANCEL; for same result, UAS must reply with a negative reply. If 
> they do not act like this, the INVITE transaction will remain active 
> (until some timeout hits).
> 
> But double check if the BYE doesn't belong to a different dialog. 
> Otherwise, I would say the UAS GW is broken here......
> 
> >> And there's even more to it. I don't know if above is OK or not, but 
> >> I would thought that now the session is ended. Nonetheless in exactly 
> >> 50 seconds I'm getting
> >>                                                                                                  
> >> 183 Session progress back to openser
> >>                                       183 Session progress back to UAC
> >> -- in another 60 seconds
> >>                                                                                                   
> >> 183 Session progress back to openser
> >>                                       183 Session progress back to UAC
> >> -- this happens 6 times every 60 seconds and then
> >>                                                                                                   
> >> 408 Request Timeout back to openser
> >>                                        ACK to UAS
> >>                                        408 Request Timeout to UAC
> >> ACK to openser
> >>
> >> Do you think it's a provider bug? Another question is how openser is 
> >> routing replies that cannot be matched to transaction
> >> as I think transaction has already been deleted after BYE and latest 
> >> 183 replies were routed
> >> by some other principle. Could please someone comment on this?
> >
> no, the previous BYE does not stop the INVITE transaction on proxy - 
> only a UAC CANCEL or UAS final reply can do it (or proxy timeout).
> The INVITE transaction ends when the 408 is received from the UAS.
> Since replies are still generated by the GW for the INVITE, again, check 
> if the BYE belongs to INVITE dialog.......
> 
> If not, the GW is twice broken :-/: first because of BYE before 200 and 
> second for keep sending replies foe INVITE after BYE.
> 
> 
> regards,
> bogdan
> 
> 
> 
> 
> 
> 

-- 
See you later,
                    Michael