Hi,
Question is: how do you deal with the multiple 200 OK responses that parallel forking in ser (using append_branches and then t_forward_nonack) deliver?
I am doing some tests and it is not really a problem ... but maybe someone has a better idea. In my configuration, the first 200 OK received is forwarded to the caller and the whole SIP session setup (caller + 1st callee). Next 200 OKs are also delivered to the caller, who happily ignores them ... it is the task of the 2nd (and 3rd, ... ) callee to at a certain point give up and send a BYE, to which the caller replies with 481 no call leg ... It all works ... but, I wonder if ser could send CANCELs after receiving the 1st 200 OK ... if yes, how? :)
I have a route_reply setup ... but only the first 200 OK gets shown ... next 200 OKs are not matched to any transaction and thus "silently" forwarded ... (via)
Cesc
Cesc Santa wrote:
I am doing some tests and it is not really a problem ... but maybe someone has a better idea. In my configuration, the first 200 OK received is forwarded to the caller and the whole SIP session setup (caller + 1st callee). Next 200 OKs are also delivered to the caller,
That is the correct behavior of a SIP proxy.
who happily ignores them ...
That is broken behavior of a SIP UA.
it is the task of the 2nd (and 3rd, ... ) callee to at a certain point give up and send a BYE, to which the caller replies with 481 no call leg ... It all works ... but, I wonder if ser could send CANCELs after receiving the 1st 200 OK ... if yes, how? :)
No, you cannot CANCEL an INVITE after having received a final response. This must be done by the caller after having sent the ACK. The UAC you have used is broken. The callee's UA tries to deal with it and does the best it can. You should use a standards-compliant SIP UA for your tests.
Regards, Olaf
inline...
2007/8/3, Olaf Bergmann Olaf.Bergmann@freenet-ag.de:
Cesc Santa wrote:
I am doing some tests and it is not really a problem ... but maybe someone has a better idea. In my configuration, the first 200 OK received is forwarded to the caller and the whole SIP session setup (caller + 1st callee). Next 200 OKs are also delivered to the caller,
That is the correct behavior of a SIP proxy.
I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
who happily ignores them ...
That is broken behavior of a SIP UA.
I think it's not specified what to do when a UA receives a second 200 OK.... it can safely ignore it, it can present a mesage to the user, it can try to mix the different audio streams, it can create a second dialog and put the first on hold, and more options.
Try to look at HERP and "early media and forking" topics....
it is the task of the 2nd (and 3rd, ... ) callee to at a
certain point give up and send a BYE, to which the caller replies with 481 no call leg ... It all works ... but, I wonder if ser could send CANCELs after receiving the 1st 200 OK ... if yes, how? :)
No, you cannot CANCEL an INVITE after having received a final response. This must be done by the caller after having sent the ACK. The UAC you have used is broken. The callee's UA tries to deal with it and does the best it can. You should use a standards-compliant SIP UA for your tests.
Hope I'm right though I think it should work "as it is" ;)
sam.
tu saps pq ho pregunto, no? :) estava jugant amb el teu modul ... i no m'envia els cancels ... pero he de dir q l'he modificat una mica, no massa, de forma q retorna no solament els contactes rebuts via multicast si no q tambe els contactes locals q ha pogut resoldre ... Els tests els faig de forma local ... sense rebre respostes del multicast ... i el q fa el SER es un fork ... pero al rebre el segon OK, no cancela la resta de branches ... dius q hauria de fer-ho automaticament?
On 8/3/07, samuel samu60@gmail.com wrote:
inline...
2007/8/3, Olaf Bergmann Olaf.Bergmann@freenet-ag.de:
Cesc Santa wrote:
I am doing some tests and it is not really a problem ... but maybe someone has a better idea. In my configuration, the first 200 OK received is forwarded to the caller and the whole SIP session setup (caller + 1st callee). Next 200 OKs are also delivered to the caller,
That is the correct behavior of a SIP proxy.
I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
who happily ignores them ...
That is broken behavior of a SIP UA.
I think it's not specified what to do when a UA receives a second 200 OK.... it can safely ignore it, it can present a mesage to the user, it can try to mix the different audio streams, it can create a second dialog and put the first on hold, and more options.
Try to look at HERP and "early media and forking" topics....
it is the task of the 2nd (and 3rd, ... ) callee to at a certain point give up and send a BYE, to which the caller replies with 481 no call leg ... It all works ... but, I wonder if ser could send CANCELs after receiving the 1st 200 OK ... if yes, how? :)
No, you cannot CANCEL an INVITE after having received a final response. This must be done by the caller after having sent the ACK. The UAC you have used is broken. The callee's UA tries to deal with it and does the best it can. You should use a standards-compliant SIP UA for your tests.
Hope I'm right though I think it should work "as it is" ;)
sam.
Sorry guys ... this mail was not ment for the list ... as it so obviously is :)
On 8/3/07, Cesc Santa cesc.santa@gmail.com wrote:
tu saps pq ho pregunto, no? :) estava jugant amb el teu modul ... i no m'envia els cancels ... pero he de dir q l'he modificat una mica, no massa, de forma q retorna no solament els contactes rebuts via multicast si no q tambe els contactes locals q ha pogut resoldre ... Els tests els faig de forma local ... sense rebre respostes del multicast ... i el q fa el SER es un fork ... pero al rebre el segon OK, no cancela la resta de branches ... dius q hauria de fer-ho automaticament?
On 8/3/07, samuel samu60@gmail.com wrote:
inline...
2007/8/3, Olaf Bergmann Olaf.Bergmann@freenet-ag.de:
Cesc Santa wrote:
I am doing some tests and it is not really a problem ... but maybe someone has a better idea. In my configuration, the first 200 OK received is forwarded to the caller and the whole SIP session setup (caller + 1st callee). Next 200 OKs are also delivered to the caller,
That is the correct behavior of a SIP proxy.
I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
who happily ignores them ...
That is broken behavior of a SIP UA.
I think it's not specified what to do when a UA receives a second 200 OK.... it can safely ignore it, it can present a mesage to the user, it can try to mix the different audio streams, it can create a second dialog and put the first on hold, and more options.
Try to look at HERP and "early media and forking" topics....
it is the task of the 2nd (and 3rd, ... ) callee to at a certain point give up and send a BYE, to which the caller replies with 481 no call leg ... It all works ... but, I wonder if ser could send CANCELs after receiving the 1st 200 OK ... if yes, how? :)
No, you cannot CANCEL an INVITE after having received a final response. This must be done by the caller after having sent the ACK. The UAC you have used is broken. The callee's UA tries to deal with it and does the best it can. You should use a standards-compliant SIP UA for your tests.
Hope I'm right though I think it should work "as it is" ;)
sam.
From the answer below, Olaf and Samuel don't seem to agree much ...
Let me attach some debug info, maybe you can see better through it than me. See attached files with debug corresponding to the first 200 OK and to the second ... I would like to think that SER actually does as Samuel said ... after the first 200 OK, all the other branches shall be automatically cancelled, thus not giving the other callees the option of sending more 200 OKs ...
On 8/3/07, samuel samu60@gmail.com wrote:
inline...
2007/8/3, Olaf Bergmann Olaf.Bergmann@freenet-ag.de:
Cesc Santa wrote:
I am doing some tests and it is not really a problem ... but maybe someone has a better idea. In my configuration, the first 200 OK received is forwarded to the caller and the whole SIP session setup (caller + 1st callee). Next 200 OKs are also delivered to the caller,
That is the correct behavior of a SIP proxy.
I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
who happily ignores them ...
That is broken behavior of a SIP UA.
I think it's not specified what to do when a UA receives a second 200 OK.... it can safely ignore it, it can present a mesage to the user, it can try to mix the different audio streams, it can create a second dialog and put the first on hold, and more options.
Try to look at HERP and "early media and forking" topics....
it is the task of the 2nd (and 3rd, ... ) callee to at a certain point give up and send a BYE, to which the caller replies with 481 no call leg ... It all works ... but, I wonder if ser could send CANCELs after receiving the 1st 200 OK ... if yes, how? :)
No, you cannot CANCEL an INVITE after having received a final response. This must be done by the caller after having sent the ACK. The UAC you have used is broken. The callee's UA tries to deal with it and does the best it can. You should use a standards-compliant SIP UA for your tests.
Hope I'm right though I think it should work "as it is" ;)
sam.
samuel wrote:
inline...
2007/8/3, Olaf Bergmann <Olaf.Bergmann@freenet-ag.de mailto:Olaf.Bergmann@freenet-ag.de>:
Cesc Santa wrote: > I am doing some tests and it is not really a problem ... but maybe > someone has a better idea. In my configuration, the first 200 OK > received is forwarded to the caller and the whole SIP session setup > (caller + 1st callee). > Next 200 OKs are also delivered to the caller, That is the correct behavior of a SIP proxy.I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
Correct: if you used append_branch (IIRC you did) the call leg will be canceled by SER. But as there is a race condition due to network latency, a 200 OK might have been sent by the receiving UA before the CANCEL was received.
> who happily ignores them ... That is broken behavior of a SIP UA.I think it's not specified what to do when a UA receives a second 200 OK.... it can safely ignore it, it can present a mesage to the user, it can try to mix the different audio streams, it can create a second dialog and put the first on hold, and more options.
Try to look at HERP and "early media and forking" topics....
No, this has nothing to do with HERFP but is a matter of forked dialog-initiating requests as you have observed. A good UAC implementation waits some time after having received the first 200 OK (and having sent the corresponding ACK) to handle subsequent 200 responses for forked requests. After some time it obviously is reasonable to drop incoming 200 responses (but notice: these responses could be matched with an ongoing call so there are options to deal with them instead of silently dropping).
> it is the task of the 2nd (and 3rd, ... ) callee to at a > certain point give up and send a BYE, to which the caller replies with > 481 no call leg ... > It all works ... but, I wonder if ser could send CANCELs after > receiving the 1st 200 OK ... if yes, how? :) No, you cannot CANCEL an INVITE after having received a final response. This must be done by the caller after having sent the ACK. The UAC you have used is broken. The callee's UA tries to deal with it and does the best it can. You should use a standards-compliant SIP UA for your tests.Hope I'm right though I think it should work "as it is" ;)
The bottom line is: SER cannot CANCEL branches after having seen an final response. If the calling UA does not handle them, the behavior you observed is the best to achieve.
Regards, Olaf
On 8/3/07, Olaf Bergmann Olaf.Bergmann@freenet-ag.de wrote:
samuel wrote:
inline...
2007/8/3, Olaf Bergmann <Olaf.Bergmann@freenet-ag.de mailto:Olaf.Bergmann@freenet-ag.de>:
Cesc Santa wrote: > I am doing some tests and it is not really a problem ... but maybe > someone has a better idea. In my configuration, the first 200 OK > received is forwarded to the caller and the whole SIP session setup > (caller + 1st callee). > Next 200 OKs are also delivered to the caller, That is the correct behavior of a SIP proxy.I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
Correct: if you used append_branch (IIRC you did) the call leg will be canceled by SER. But as there is a race condition due to network latency, a 200 OK might have been sent by the receiving UA before the CANCEL was received.
Hi Olaf,
It seems that, for some reason, my SER is not cancelling the branches after reception of the first 200 OK ... any idea? where would the code be? For testing, one of the endpoints is asterisk's echo ... The other callee is a phone, and apart from sending 100 and 183, I wait some seconds before I decide to pick up ... enough for SER to send a CANCEL, which never happends.
The second 200 OK is not matched to any transaction, so it would seem like SER has already deleted it ... when does that happen? I've done some stuff with SER ... but the TM module is really hardcore :)
Cesc Santa wrote:
On 8/3/07, Olaf Bergmann Olaf.Bergmann@freenet-ag.de wrote:
samuel wrote:
inline...
2007/8/3, Olaf Bergmann <Olaf.Bergmann@freenet-ag.de mailto:Olaf.Bergmann@freenet-ag.de>:
Cesc Santa wrote: > I am doing some tests and it is not really a problem ... but maybe > someone has a better idea. In my configuration, the first 200 OK > received is forwarded to the caller and the whole SIP session setup > (caller + 1st callee). > Next 200 OKs are also delivered to the caller, That is the correct behavior of a SIP proxy.I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
Correct: if you used append_branch (IIRC you did) the call leg will be canceled by SER. But as there is a race condition due to network latency, a 200 OK might have been sent by the receiving UA before the CANCEL was received.
Hi Olaf,
It seems that, for some reason, my SER is not cancelling the branches after reception of the first 200 OK ... any idea? where would the code be? For testing, one of the endpoints is asterisk's echo ... The other callee is a phone, and apart from sending 100 and 183, I wait some seconds before I decide to pick up ... enough for SER to send a CANCEL, which never happends.
The second 200 OK is not matched to any transaction, so it would seem like SER has already deleted it ... when does that happen? I've done some stuff with SER ... but the TM module is really hardcore :)
So, which version of SER are you using? IIRC---for some reason, I did not recently check with the TM code---the outstanding branches are cancelled automatically after receiving a 200 OK in recent versions of the TM module. Not sure here---it simply works for us.
Regards, Olaf
On 8/3/07, Olaf Bergmann Olaf.Bergmann@freenet-ag.de wrote:
Cesc Santa wrote:
On 8/3/07, Olaf Bergmann Olaf.Bergmann@freenet-ag.de wrote:
samuel wrote:
inline...
2007/8/3, Olaf Bergmann <Olaf.Bergmann@freenet-ag.de mailto:Olaf.Bergmann@freenet-ag.de>:
Cesc Santa wrote: > I am doing some tests and it is not really a problem ... but maybe > someone has a better idea. In my configuration, the first 200 OK > received is forwarded to the caller and the whole SIP session setup > (caller + 1st callee). > Next 200 OKs are also delivered to the caller, That is the correct behavior of a SIP proxy.I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
Correct: if you used append_branch (IIRC you did) the call leg will be canceled by SER. But as there is a race condition due to network latency, a 200 OK might have been sent by the receiving UA before the CANCEL was received.
Hi Olaf,
It seems that, for some reason, my SER is not cancelling the branches after reception of the first 200 OK ... any idea? where would the code be? For testing, one of the endpoints is asterisk's echo ... The other callee is a phone, and apart from sending 100 and 183, I wait some seconds before I decide to pick up ... enough for SER to send a CANCEL, which never happends.
The second 200 OK is not matched to any transaction, so it would seem like SER has already deleted it ... when does that happen? I've done some stuff with SER ... but the TM module is really hardcore :)
So, which version of SER are you using? IIRC---for some reason, I did not recently check with the TM code---the outstanding branches are cancelled automatically after receiving a 200 OK in recent versions of the TM module. Not sure here---it simply works for us.
Regards, Olaf
I'm using 0.9.6 ... It is good that it works in yours (which r u using?) ... i can try to track the problem in the cvs ...
Cesc
Got it!!! Took me a bit of fighting, but found it ...
A couple of small bugs in 0.9.6 (tm/t_cancel.c/h, functions should_cancel_branch and cancel_branch)... which prevent CANCELs from being sent ... I will be sending a patch to the devel list ...
Cesc
On 8/3/07, Cesc Santa cesc.santa@gmail.com wrote:
On 8/3/07, Olaf Bergmann Olaf.Bergmann@freenet-ag.de wrote:
Cesc Santa wrote:
On 8/3/07, Olaf Bergmann Olaf.Bergmann@freenet-ag.de wrote:
samuel wrote:
inline...
2007/8/3, Olaf Bergmann <Olaf.Bergmann@freenet-ag.de mailto:Olaf.Bergmann@freenet-ag.de>:
Cesc Santa wrote: > I am doing some tests and it is not really a problem ... but maybe > someone has a better idea. In my configuration, the first 200 OK > received is forwarded to the caller and the whole SIP session setup > (caller + 1st callee). > Next 200 OKs are also delivered to the caller, That is the correct behavior of a SIP proxy.I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
Correct: if you used append_branch (IIRC you did) the call leg will be canceled by SER. But as there is a race condition due to network latency, a 200 OK might have been sent by the receiving UA before the CANCEL was received.
Hi Olaf,
It seems that, for some reason, my SER is not cancelling the branches after reception of the first 200 OK ... any idea? where would the code be? For testing, one of the endpoints is asterisk's echo ... The other callee is a phone, and apart from sending 100 and 183, I wait some seconds before I decide to pick up ... enough for SER to send a CANCEL, which never happends.
The second 200 OK is not matched to any transaction, so it would seem like SER has already deleted it ... when does that happen? I've done some stuff with SER ... but the TM module is really hardcore :)
So, which version of SER are you using? IIRC---for some reason, I did not recently check with the TM code---the outstanding branches are cancelled automatically after receiving a 200 OK in recent versions of the TM module. Not sure here---it simply works for us.
Regards, Olaf
I'm using 0.9.6 ... It is good that it works in yours (which r u using?) ... i can try to track the problem in the cvs ...
Cesc
2007/8/3, Olaf Bergmann Olaf.Bergmann@freenet-ag.de:
samuel wrote:
inline...
2007/8/3, Olaf Bergmann <Olaf.Bergmann@freenet-ag.de mailto:Olaf.Bergmann@freenet-ag.de>:
Cesc Santa wrote: > I am doing some tests and it is not really a problem ... but maybe > someone has a better idea. In my configuration, the first 200 OK > received is forwarded to the caller and the whole SIP sessionsetup
> (caller + 1st callee). > Next 200 OKs are also delivered to the caller, That is the correct behavior of a SIP proxy.I think the proper forking behaviour is to send a CANCEL to all branches upon receiving a 200 from one of them and I think that SER does this automatically... isn't it??
Correct: if you used append_branch (IIRC you did) the call leg will be canceled by SER. But as there is a race condition due to network latency, a 200 OK might have been sent by the receiving UA before the CANCEL was received.
You're totally right! I was speaking about the written standard....
> who happily ignores them ... That is broken behavior of a SIP UA.I think it's not specified what to do when a UA receives a second 200 OK.... it can safely ignore it, it can present a mesage to the user, it can try to mix the different audio streams, it can create a second dialog and put the first on hold, and more options.
Try to look at HERP and "early media and forking" topics....
No, this has nothing to do with HERFP but is a matter of forked dialog-initiating requests as you have observed. A good UAC implementation waits some time after having received the first 200 OK (and having sent the corresponding ACK) to handle subsequent 200 responses for forked requests. After some time it obviously is reasonable to drop incoming 200 responses (but notice: these responses could be matched with an ongoing call so there are options to deal with them instead of silently dropping).
Right.
> it is the task of the 2nd (and 3rd, ... ) callee to at a > certain point give up and send a BYE, to which the caller replieswith
> 481 no call leg ... > It all works ... but, I wonder if ser could send CANCELs after > receiving the 1st 200 OK ... if yes, how? :) No, you cannot CANCEL an INVITE after having received a final response. This must be done by the caller after having sent the ACK. The UAC you have used is broken. The callee's UA tries to deal with it and does the best it can. You should use a standards-compliant SIP UA for your tests.Hope I'm right though I think it should work "as it is" ;)
The bottom line is: SER cannot CANCEL branches after having seen an final response. If the calling UA does not handle them, the behavior you observed is the best to achieve.
Regards, Olaf
Thanks! Samuel.
-
Cesc Santa -
Olaf Bergmann -
samuel