Hi!
I just had a look at RFC 3261, section 8.1.3.5 Processing 4xx Responses.
There it stands:
"
In all of the above cases, the request is retried by creating a new
request with the appropriate modifications. This new request
constitutes a new transaction and SHOULD have the same value of the
Call-ID, To, and From of the previous request, but the CSeq should
contain a new sequence number that is one higher than the previous.
With other 4xx responses, including those yet to be defined, a retry
may or may not be possible depending on the method and the use case.
"
I think that makes it pretty simple: we should use a different pair of
call-id+local_tag only if we really mean a different call, not just a
retried request with authentication or alike. For the cases in this
section, we only need a different cseq, which always happens when
AmSipDialog sends the request.
In the case of a redirect answer (3xx), only the Via-branch should be
different (described in section 8.1.3.4 Processing 3xx Responses).
Cheers
Raphael.
On 21.10.10 23:29, Stefan Sayer wrote:
[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
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
