Thanks, Dale
I meant subscriptions. The current sequence is
User logs-in in operational mode A:
->Initial REGISTER feature-tag A
->subscription to N different event packages (common no matter which
operational mode selected)
User changes operational mode on the fly
->automatic unsubscription to N event-packages
->automatic deregistration feature-tag A
->automatic initial registration feature-tag B (new Call-Id, CSeq is set
to 1)
->automatic subscription to N event-packages
The sequence we are wondering to explore is
User logs-in in operational mode A:
->Initial REGISTER feature-tag A
->subscription to N different event packages (common no matter which
operational mode selected)
User changes operational mode on the fly
->automatic refresh REGISTER feature-tag B
i.e. reuse "old" subscriptions (i should have better said keep)
"Dale Worley" <dwor...@nortel.com>
17/03/2009 21:26
Para: javier.ferreirogar...@telefonica.es
cc: sip-implementors@lists.cs.columbia.edu
Asunto: Re: [Sip-implementors] Feature tags register modification
El medio ambiente y nuestros bosques agradecen tu colaboración para
ayudarnos a ahorrar papel, por eso no me imprimas si no es imprescindible.
Telefónica Móviles España, S.A.
On Tue, 2009-03-17 at 16:29 +0100, javier.ferreirogar...@telefonica.es
wrote:
> The current approach, when changing operational mode on the fly, is to
> unsubscribe prior to automatic deregistration, then perform initial
> registration of the new "feature tag" and perform initial subscription
to
> all event-packages. The overhead in terms of SIP messages is
significant,
> so we are wondering if it is possible to reuse "old" subscriptions. When
> unregistering old contact and registering the new; the IP address in the
> Contact keeps the same, the only item that changes is the feature tag.
> Is this allowed according to RFC 3261?
I assume you mean "registrations" instead of "subscriptions".
Certainly, the sequence of REGISTER requests that you propose is
*allowed* by RFC 3261. And since the actual contact URI (as opposed to
the field-parameter attached to it) does not change, the routing of
requests for that AOR would not change -- the outgoing request-URI would
still be <sip:10.232.110.202>. So I don't see why this case is
interesting.
I suspect you have not made clear what you think the trouble would be.
Dale
_____________________________________________________________________
Mensaje analizado y protegido por Telefonica Empresas
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
