I was testing a scenario whith parallel forking (multiple registers) where 2 endpoints answer near simultaniously. When phone that was just a bit slower hangs up, the BYE gets forwarded to the caller and thus the connection is terminated. This is as far as I know for stateful transactions (t_relay())
I always assumed in this scenario the state machine in kamailio would prevent this kind of behavior by itself. Is there a way to prevent these messages being forwarded?
Hello,
the BYE must have a different To-tag than the other answered branch and the caller device should not close the connected call/branch.
Look at the To-tags in the two branches and see if they are different.
Cheers, Daniel
On 29/06/15 14:17, Daniel Tryba wrote:
I was testing a scenario whith parallel forking (multiple registers) where 2 endpoints answer near simultaniously. When phone that was just a bit slower hangs up, the BYE gets forwarded to the caller and thus the connection is terminated. This is as far as I know for stateful transactions (t_relay())
I always assumed in this scenario the state machine in kamailio would prevent this kind of behavior by itself. Is there a way to prevent these messages being forwarded?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Monday 29 June 2015 17:29:17 Daniel-Constantin Mierla wrote:
the BYE must have a different To-tag than the other answered branch and the caller device should not close the connected call/branch.
Look at the To-tags in the two branches and see if they are different.
Thanks for the pointer.
Yes the BYE has indeed a different to tag than the answered leg. The caller is an Asterisk 1.4. With a near default sip configuration as fas as I can see so effectively pedantic=no, this this explains the behavior: http://lists.digium.com/pipermail/asterisk-dev/2009-April/037810.html
"For instance, RFC 3261 plainly spells out that the way to identify whether an incoming message belongs to a specific dialog is to check the call-id, to tag, and from tag. With pedantic mode disabled, all we look at is the call-id because in the majority of situations, the call-id is suitable for identifying which dialog the request belongs to. However, if you know that tag checking is important, then it will be enabled by turning on pedantic mode."
This is a custom machine, I'm a bit hesitant to flip the pedantic switch. I'll report a bug to the maintainer of that setup :)
-
Daniel Tryba -
Daniel-Constantin Mierla