Hi Saul,
Just to clarify - while the call is still in early stage, the control is
done at transaction level (the INVITE transaction) - if transaction is
successful (200OK) -> call established; if transaction fails (negative
reply) -> call fails.
So, the dialog module is not interested in the CANCEL -> it will wait to
see the feedback on the INVITE level, like the 487 reply (as a result of
the CANCEL being accepted).
The BYE (instead of CANCEL) works in a similar way - the dialog module
will simply wait to see what will happen with the INVITE.
So, from standard dialog state, the dialog module does not care about
the CANCELs or BYEs in early state.
Of course, things are a bit different when using topology hiding with
dialog module - there you have the "topo hide" the BYE also ;).....and
this needs to be fixed
Regards,
Bogdan
On 11/17/2011 02:24 PM, Saúl Ibarra Corretgé wrote:
Hi,
On Nov 17, 2011, at 12:53 PM, Vlad Paiu wrote:
Hello,
The problem lies in the fact that the device send BYE while the dialog was not
established yet, when in fact a Cancel should have been used.
The caller MAY use a BYE instead of a CANCEL to terminate a dialog in the early
stage, that is, if it received a 101-199 response with a to-tag. (RFC 3261, sec
15)
Since no SIP trace was provided I don't know if that was the case. Anyway,
would OpenSIPS handle that situation correctly?
Regards,
--
Saúl Ibarra Corretgé
AG Projects
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
