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? 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? Thanks,
See you later, Michael
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? 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? Thanks,
See you later, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
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
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
This is what I though it should look like. Nonetheless they're sending BYE right after 183 and I'm wondering if I should complain about it or this is something I overlooked in SIP specification. Also I didn't get which ACK do you mean? As you can see the only ACK in this session is very last ACK and I thought that session should be ended after I replied 200 OK to their BYE.
Michael
On Friday 02 September 2005 01:54 pm, 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? 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? Thanks,
See you later, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
to the 200 OK the UAC should send a ACK
Iqbal
Michael Ulitskiy wrote:
This is what I though it should look like. Nonetheless they're sending BYE right after 183 and I'm wondering if I should complain about it or this is something I overlooked in SIP specification. Also I didn't get which ACK do you mean? As you can see the only ACK in this session is very last ACK and I thought that session should be ended after I replied 200 OK to their BYE.
Michael
On Friday 02 September 2005 01:54 pm, 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? 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? Thanks,
See you later, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
Hi Iqbal
If I got the diagram right and it's about question 1, the 200 OK is for BYE, so there is no ACK
regards, bogdan
Iqbal wrote:
to the 200 OK the UAC should send a ACK
Iqbal
Michael Ulitskiy wrote:
This is what I though it should look like. Nonetheless they're sending BYE right after 183 and I'm wondering if I should complain about it or this is something I overlooked in SIP specification. Also I didn't get which ACK do you mean? As you can see the only ACK in this session is very last ACK and I thought that session should be ended after I replied 200 OK to their BYE.
Michael
On Friday 02 September 2005 01:54 pm, 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? 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? Thanks,
See you later, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Yes, you got it right. UAC has never received 200 OK for INVITE and had nothing to ACK.
Michael
On Friday 02 September 2005 02:47 pm, Bogdan-Andrei Iancu wrote:
Hi Iqbal
If I got the diagram right and it's about question 1, the 200 OK is for BYE, so there is no ACK
regards, bogdan
Iqbal wrote:
to the 200 OK the UAC should send a ACK
Iqbal
Michael Ulitskiy wrote:
This is what I though it should look like. Nonetheless they're sending BYE right after 183 and I'm wondering if I should complain about it or this is something I overlooked in SIP specification. Also I didn't get which ACK do you mean? As you can see the only ACK in this session is very last ACK and I thought that session should be ended after I replied 200 OK to their BYE.
Michael
On Friday 02 September 2005 01:54 pm, 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? 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? Thanks,
See you later, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
I stand corrected yes the 200 OK is for the BYE, I misread and thought the 200 OK was from UAs to openser, and then from openser to UAC,
Iqbal
Bogdan-Andrei Iancu wrote:
Hi Iqbal
If I got the diagram right and it's about question 1, the 200 OK is for BYE, so there is no ACK
regards, bogdan
Iqbal wrote:
to the 200 OK the UAC should send a ACK
Iqbal
Michael Ulitskiy wrote:
This is what I though it should look like. Nonetheless they're sending BYE right after 183 and I'm wondering if I should complain about it or this is something I overlooked in SIP specification. Also I didn't get which ACK do you mean? As you can see the only ACK in this session is very last ACK and I thought that session should be ended after I replied 200 OK to their BYE.
Michael
On Friday 02 September 2005 01:54 pm, 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? 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? Thanks,
See you later, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
.
-
Bogdan-Andrei Iancu -
Iqbal -
Michael Ulitskiy