Re: [Sip-implementors] Network Initiated De-registration

[Paul Kyzivat]

On 10/6/17 10:29 PM, Dale R. Worley wrote:

Paul Kyzivat  writes:

On 10/6/17 1:04 PM, Abhishek Jain wrote:

1. Under what senarios or conditions, Network would initiate deregistration
to a UE ?


The only reason that is covered by ietf sip standards is expiration of
the registration without renewal. Other reasons would be based on
policy. For instance, if the account for the AoR has beed deleted.


Thinking about it, I don't think that there's a general way for the
network to signal to the UA (UE) that it has been prematurely
deregistered, that is, deregistered before the expiration of a
previously granted registration.  Of course, once the proxy/registrar
isn't willing to route calls to the UA, it *is* deregistered, and of
course, it can refuse to accept calls originating from the UA.


The "reg" event package (RFC3680) can be used to discover that you have 
been deregistered.


Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] B2BUA behavior in correlation of Pre-Conditions & Multiple Early Dialogs

[Dale R. Worley]

VARUN BHATIA  writes:
> As a B2BUA what is the expectation when it is sitting behind a forking
> proxy (IMS Application Server) and it is sending back multiple early
> dialogs back.
>
> 1. It should ideally send it back transparently to ingress i.e.
> creating multiple early dialogs at ingress leg too. (UAC should be
> capable of supporting early dialogs)
> 2. Doing inter-working with ingress and rather than sending multiple
> early dialog toward ingress it should send new offer in UPDATE.
> (Though in this case UAC should support UPDATE method in early
> dialog).

As Paul said, the B2BUA must present itself as a proper UAS on the
ingress side and as a proper UAC on the egress side.  Other than that,
it can do anything that accomplishes your goal.

But as Paul also said, it is complicated to bundle multiple early
dialogs on the egress side into one early dialog on the ingress side.

> In the above scenario if Pre-condition is been expected then will
> there be any change or it should be same.
> As per my understanding forking proxy should handle, in this scenario,
> once the pre-condition has been exchanged & resource reservation has
> been done. AS should not send multiple early dialog towards B2BUA.

A forking proxy is simpler, because the proxy doesn't actually handle
any of the precondition processing, it just passes the messages
through.

A UAC that is handling preconditions on multiple early dialogs has to
allocate resources for each of them, in coordination with each early
dialog's precondition negotiation.

It would be complicated for a B2BUA to merge precondition processing in
multiple early dialogs into precondition processing in a single early
dialog, because the B2BUA would have to merge the demands of all of the
UASs into a single demand for reservations on the ingress side.
Depending on the range of demands that can be expressed in
preconditions, it might be difficult to create such "union"
preconditions.

> Though i am trying to find reference in RFC or 3GPP standard but not
> yet able to find any.

The difficulty is that the problem is implicit -- Can you figure out how
to implement a B2BUA that has the features you want?  The standards only
prescribe the requirements that the B2BUA must conform to, not how to
design one that does what you want.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Network Initiated De-registration

[Dale R. Worley]

Paul Kyzivat  writes:
> On 10/6/17 1:04 PM, Abhishek Jain wrote:
>> 1. Under what senarios or conditions, Network would initiate deregistration
>> to a UE ?
>
> The only reason that is covered by ietf sip standards is expiration of 
> the registration without renewal. Other reasons would be based on 
> policy. For instance, if the account for the AoR has beed deleted.

Thinking about it, I don't think that there's a general way for the
network to signal to the UA (UE) that it has been prematurely
deregistered, that is, deregistered before the expiration of a
previously granted registration.  Of course, once the proxy/registrar
isn't willing to route calls to the UA, it *is* deregistered, and of
course, it can refuse to accept calls originating from the UA.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Network Initiated De-registration

[Abhishek Jain]

Thank you Paul for your quick response.
Appreciate it.

Regards
Abhishek

On Fri, Oct 6, 2017 at 3:18 PM, Paul Kyzivat  wrote:

> On 10/6/17 1:04 PM, Abhishek Jain wrote:
>
>> Hi,
>>
>> 1. Under what senarios or conditions, Network would initiate
>> deregistration
>> to a UE ?
>>
>
> The only reason that is covered by ietf sip standards is expiration of the
> registration without renewal. Other reasons would be based on policy. For
> instance, if the account for the AoR has beed deleted.
>
> Thanks,
> Paul
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] B2BUA behavior in correlation of Pre-Conditions & Multiple Early Dialogs

[Paul Kyzivat]

On 10/6/17 2:42 PM, VARUN BHATIA wrote:

Hello,

As a B2BUA what is the expectation when it is sitting behind a forking
proxy (IMS Application Server) and it is sending back multiple early
dialogs back.

1. It should ideally send it back transparently to ingress i.e.
creating multiple early dialogs at ingress leg too. (UAC should be
capable of supporting early dialogs)


IMO this is the straightforward thing to do.


2. Doing inter-working with ingress and rather than sending multiple
early dialog toward ingress it should send new offer in UPDATE.
(Though in this case UAC should support UPDATE method in early
dialog).


I realize (sadly) that there may be some UAs that don't properly handle 
multiple early dialogs, and some B2BUAs may want to make them work by 
handling the complications for them. OTOH, doing anything other that (1) 
is tricky. The guiding rule is that the B2BUA must follow all the rules 
for a UAS on the ingress side and (independently) for a UAC on the 
egress side. There really aren't any other rules. Be as creative as you 
like.



In the above scenario if Pre-condition is been expected then will
there be any change or it should be same.
As per my understanding forking proxy should handle, in this scenario,
once the pre-condition has been exchanged & resource reservation has
been done. AS should not send multiple early dialog towards B2BUA.


Preconditions could make this very difficult to do.


Though i am trying to find reference in RFC or 3GPP standard but not
yet able to find any.


I'm not at all up to date on what in in 3GPP standards. But frankly I 
would be very surprised to find anything.


Thanks,
Paul


Your expert inputs are much appreciated and if it can be provided in
some reference to standard it will be very helpful.




___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Network Initiated De-registration

[Paul Kyzivat]

On 10/6/17 1:04 PM, Abhishek Jain wrote:

Hi,

1. Under what senarios or conditions, Network would initiate deregistration
to a UE ?


The only reason that is covered by ietf sip standards is expiration of 
the registration without renewal. Other reasons would be based on 
policy. For instance, if the account for the AoR has beed deleted.


Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] B2BUA behavior in correlation of Pre-Conditions & Multiple Early Dialogs

[VARUN BHATIA]

Hello,

As a B2BUA what is the expectation when it is sitting behind a forking
proxy (IMS Application Server) and it is sending back multiple early
dialogs back.

1. It should ideally send it back transparently to ingress i.e.
creating multiple early dialogs at ingress leg too. (UAC should be
capable of supporting early dialogs)
2. Doing inter-working with ingress and rather than sending multiple
early dialog toward ingress it should send new offer in UPDATE.
(Though in this case UAC should support UPDATE method in early
dialog).

In the above scenario if Pre-condition is been expected then will
there be any change or it should be same.
As per my understanding forking proxy should handle, in this scenario,
once the pre-condition has been exchanged & resource reservation has
been done. AS should not send multiple early dialog towards B2BUA.

Though i am trying to find reference in RFC or 3GPP standard but not
yet able to find any.

Your expert inputs are much appreciated and if it can be provided in
some reference to standard it will be very helpful.


-- 
Thanks,
Varun Bhatia
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Network Initiated De-registration

[Abhishek Jain]

Hi,

1. Under what senarios or conditions, Network would initiate deregistration
to a UE ?

Regards
Abhishek
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] rules for From-tag generation in forking B2BUA

[Andrew Pogrebennyk]

Thanks everybody for the responses!
I will get back to you when I get a clear understanding of the involved
mechanism.

Best regards,
Andrew

On 10/05/2017 03:21 AM, Dale R. Worley wrote:
> There is at least this consideration:  The B2BUA can generate multiple
> outgoing *dialogs* from one incoming request, acting as a UAC generating
> multiple dialogs.  In that case, each outgoing request, each dialog, has
> to have a unique Call-Id.  Each dialog has to have its own from-tag, and
> taken collectively, the from tags have to be statistically random.  In
> particular, you can't just use the same from-tag on each outgoing
> dialog.
> 
> Alternatively, the B2BUA can (in principle) generate one outgoing dialog
> (with its unique Call-Id and its from-tag) and then (as UACs are
> allowed) immediately fork it to multiple destinations.  So what you see
> on the wire is multiple outgoing requests with the same Call-Id, the
> same from-tag, and different Vias.
> 
> In the second case, any UA downstream can recognize that if it receives
> requests coming from more than one of these forks, it can reject all but
> the first.  But that shouldn't cause any problems in practice.
> 
> So the only thing that shows up as a rule is that the B2BUA has to be
> consistent whether its outgoing requests are forks of one dialog, or
> separate dialogs; that is, if the Call-Ids are the same, the from-tags
> must be the same, and if the Call-Ids are different, the from-tags
> should be randomized.
> 
> There is a third case, the B2BUA which is trying to pretend it is a
> proxy, or "quasi-proxy".  But those always use the same Call-Id and
> from-tag on their outgoing requests as was present on the incoming
> request.
> 
> Now it's possible that the downstream equipment you are referring to has
> some narrow rules that interact badly with one of these modes of
> operation.  I suggest you get a clear description of the mechanism that
> is involved and report back about that.  Then we might be able to
> clarify the choices.
> 
> Dale

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors