[email protected] wrote:
Hello
On Thu, 21 Oct 2010 18:07:32 +0200
Raphael Coeffic <[email protected]> wrote:
On 18.10.10 11:11, Stefan Sayer wrote:
Антон Загорский wrote:
Hello Stefan.
Yes. You will need a new local tag and session id
I don't change local tag and session id and just call sendInvite
again. And this work fine.
When will my algorithm fails?
potentially this does not work: if any proxy on the way or the UAS
still has not timed out the dialog (identified by tag/callid), it
will think that the new INVITE belings to the old dialog. Also, this
may break your billing system if there is any.
AmSipDialog will automatically increase the cseq by one, and a new
via-branch will be created anyway. Both cseq and via-branch are part
of the transaction matching, which means that the second INVITE would
not match the first one. In my opinion, it will not even match an
existing dialog, as the dialog would rather have been killed/never
created after the UAS sent an error back.
The only issue is the To-tag. the 'uac_auth' module implements a
similar use case (see UACAuth.cpp:165 to 176).
If we are talking entire SIP then SIP session indentifies by triple
Call-ID, To-Tag, From-Tag.
this is dialog matching (which probably is used e.g. by any accounting
system if there is any)
1. Why does SEMS identify SIP session be means of other parameters?
raphael talks about transaction matching above (which would come in
the proxy first to filter out retransmissions, what I was worried about)
2. UACAuth.cpp just clears From-Tag. sendRequest(..) doesn't populate it
with new value. Is it right?
it clears remote-tag, not From-tag.
it does that if the request that is resent is supposed to create a new
dialog (outgoing dialog establishing INVITE failed). (otherwise the
UAS would think the request should belonged to the other dialog).
3. Can I just generate new Call-ID and change it directly?
yes; for outgoing calls, you can do that before the dialog is established.
Stefan
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
