2009/7/20 JC <jc.hu...@tom.com>:
> My scenario is as follows, one SIP client sends one fresh SUBSCRIBE to
> SIP server via TCP, and SIP server sends 200OK back immediately.
> Unfortunately, SIP client does incorrect thing to retransmit SUBSCRIBE
> once before it gets final response.
> In this error case, when SIP server
> sends 200OK, associated transaction releases immediately.
This is correct according to RFC 3261:
17.2.2 Non-INVITE Server Transaction
[...]
When the server transaction enters the "Completed" state, it MUST set
Timer J to fire in 64*T1 seconds for unreliable transports, and zero
seconds for reliable transports.
> So for
> retransmitted SUBSCRIBE, transaction layer will regard it as a new msg,
> not retransmitted one, and will create a new transation. And dialog
> layer cann't find one matched dialog for retranmited msg because TO tag
> not match, so maybe will create a new dialog.
>
> My question is how to defend the issue in SIP server. I think
> transaction layer cann't do anything.
No, it's the correct behaivour (in the server).
> How about dialog layer, similar
> like early notify process to change dialog matching condition?
Note that, an UAC could open different dialogs against the same destination:
1) Alice can call twice to Bob (at the same time).
2) Alice can subscribe twice to Bob (at the same time).
However I've a doubt here (point 2) since if Alice susbcribes twice to
Bob, having both SUBSCRIBE requests the same "Contact", "From" and
"RURI"... it doesn't make sense for the server to mantain two
subscriptions since the server should send the *exact* NOTIFY's twice
to the same "Contact".
Anyhow, if the Contact of the second request is different, it should
create a new subscription. This is, the server shouldn't "discard" the
second SUBSCRIBE at dialog level (From tag, To tag, Call-ID).
> Or let
> SIP server application layer check it, e.g., the user has been
> subscribed and reject it?
What I would do is:
- If the server receives a SUBSCRIBE with a From, RURI and Contact
matching an existing subscription, the server would send 200 and the
NOTIFY (as usual), but wouldn't store it in the subscription dialogs
(it already exists, no need to add it again as it's useless).
--
Iñaki Baz Castillo
<i...@aliax.net>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
