Jānis Rukšāns | 5 Jul 22:59 2012
Picon

Subscriber behaviour on expiration

Hi,

What is the recommended behaviour if the subscription is about to expire
but the subscriber does not want to extend the subscription?

Both RFC 3265 and draft-ietf-sipcore-rfc3265bis seem to focus on long
running subscriptions, which are refreshed indefinitely until explicitly
terminated by an action from the user. While the same could be done for
(seemingly) short term subscriptions, it also makes sense to simply let
the subscription to time out. However RFC 3265 is not very clear on this
topic, only mentioning that:

        If a SUBSCRIBE request to refresh a subscription fails [..], the
        original subscription is still considered valid for the duration
        of the most recently known "Expires" value [..]

I am considering the following options:

* Wait for the final NOTIFY with reason=timeout, and consider the
subscription terminated if it is not received within some fixed time
after the subscription has expired (64*T1 seems like a good choice).

* Explicitly unsubscribe by sending SUBSCRIBE with Expires: 0

* Consider the subscription as terminated as soon as it expires, without
waiting for the final NOTIFY. If the notifier does send it, reply with
481 Subscription Does Not Exist.

By the way, draft-ietf-sipcore-rfc3265bis-09 section 4.2.2 erroneously
states that 'it is perfectly valid for a SUBSCRIBE request with a
(Continue reading)

Worley, Dale R (Dale | 5 Jul 23:56 2012

Re: Subscriber behaviour on expiration

On Thu, 2012-07-05 at 23:59 +0300, Jānis Rukšāns wrote:
> What is the recommended behaviour if the subscription is about to expire
> but the subscriber does not want to extend the subscription?

It's not clear to me exactly which process's behavior you are
considering, and what aspect of the process's behavior you are
interested in.  I think you are considering the subscriber's behavior.

Since the subscriber knows when the subscription is due to expire, and
knows that the notifier will send no further notifications after that
point, the subscriber knows exactly when the subscription expires, and
after that point, not to expect any more NOTIFYs.

If the notifier behaves correctly and there are no network problems, the
subscriber should receive a NOTIFY with "Subscription-State:
terminated".  But if there are network problems, that NOTIFY may not
arrive.  Nonetheless, the subscriber knows that the subscription has
expired.  The subscriber should certainly not assume that the
subscription is continuing just because it has not received the
terminating NOTIFY.

The notifier can send NOTIFY with "Subscription-State: termianted" at
any time, and the subscriber should take appropriate action if it wants
a continuing subscription.

As you note, the subscriber can send a SUBSCRIBE with "Expires: 0" to
terminate the subscription early.  But it may choose not to.

Dale

(Continue reading)

Naarumanchi Kaushik | 6 Jul 07:23 2012
Picon

Call forward enabled and user calling himself

Hi All,

I have two questions:
1. When a user calls himself(to the same endpoint), he will get User Busy
response as his device is already busy. So a User busy response is sent
based on his device status and not based on comparision between From and To
URIs. Is this correct?
2. If call forward always is enabled for this user, and if he calls
himself, then giving priority to call forward is correct or not? Should
this also be a User Busy response?

N.V.S.Kaushik.
Sr. Software Engineer,
HelloSoft, Hyderabad
Ph: +91-80081 78921
manju nath | 6 Jul 10:47 2012
Picon

Doubt reagrding IMS feature tag for MMS(multimedia messaging service)

  Hi all,

      Iam working on IMS client framework project, in which we use CPM
enabler for sending MMS through PAGER & LARGE mode messages of CPM.

      I have the follwoing doubts in sending MMS(multimedia message
service) using LARGE mode standalone message of CPM enabler.

      1) To send large mode message we use SIP INVITE request to establish
a session. In which how can i mention that this INVITE is for MMS not for
voice call ?? is there any fature tag related to MMS ??
      2) what should be the maximum length(number of charecter) of
Conversation & Contribution ID headers?
      3) what will be the extension of an MMS file like pictute have .jpg
etc?

Kindly help me

Thanks in advance.... :)

--

-- 
*Thanks & Regards,*
*Manjunath.jootoor.*
Jānis Rukšāns | 6 Jul 13:45 2012
Picon

Re: Subscriber behaviour on expiration

Hi,

On Thu, 2012-07-05 at 17:56 -0400, Worley, Dale R (Dale) wrote:
> It's not clear to me exactly which process's behavior you are
> considering, and what aspect of the process's behavior you are
> interested in.  I think you are considering the subscriber's behavior.

Right.

> Since the subscriber knows when the subscription is due to expire, and
> knows that the notifier will send no further notifications after that
> point, the subscriber knows exactly when the subscription expires, and
> after that point, not to expect any more NOTIFYs.

In this case the final NOTIFY (3265bis 4.2.1.4 2nd paragraph) seems to
be redundant, since the subscriber already knows that the subscription
has expired.

Thanks,
Jānis

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Paul Kyzivat | 6 Jul 16:39 2012
Picon

Re: Call forward enabled and user calling himself

On 7/6/12 1:23 AM, Naarumanchi Kaushik wrote:
> Hi All,
>
> I have two questions:
> 1. When a user calls himself(to the same endpoint), he will get User Busy
> response as his device is already busy. So a User busy response is sent
> based on his device status and not based on comparision between From and To
> URIs. Is this correct?
> 2. If call forward always is enabled for this user, and if he calls
> himself, then giving priority to call forward is correct or not? Should
> this also be a User Busy response?

Your questions are mostly choices an implementer can make.

In general you would not decide an incoming call is from you based on 
the From address, because there can be many devices sharing the same 
AOR. You could check the Contact address and refuse the call if it is 
your own. But that won't work if there is a B2BUA in the call path.

I've been waiting to hear of a possible pathology of this sort:
You call yourself, or call somewhere that is routed back to you. Then 
your phone gives you a call waiting indication. You put your current 
call (the outgoing one) on hold and answer the incoming call. But then 
you hear silence because the caller is on hold. You can then switch 
between calls, but one end is always on hold. :-)

Probably we don't hear about this in practice because in general you 
won't be able to put the outgoing call on hold to take the incoming call 
because the outgoing call still hasn't been answered. (That may not 
always be true, depending on what middle boxes are in the call.) But 
(Continue reading)

Paul Kyzivat | 6 Jul 17:07 2012
Picon

Re: Doubt reagrding IMS feature tag for MMS(multimedia messaging service)

Presumably your invite will contain an offer that offers msrp and not 
voice or video. Isn't that sufficient? Any endpoint that doesn't support 
msrp will reject such an invite.

	Thanks,
	Paul

On 7/6/12 4:47 AM, manju nath wrote:
>    Hi all,
>
>        Iam working on IMS client framework project, in which we use CPM
> enabler for sending MMS through PAGER&  LARGE mode messages of CPM.
>
>        I have the follwoing doubts in sending MMS(multimedia message
> service) using LARGE mode standalone message of CPM enabler.
>
>        1) To send large mode message we use SIP INVITE request to establish
> a session. In which how can i mention that this INVITE is for MMS not for
> voice call ?? is there any fature tag related to MMS ??
>        2) what should be the maximum length(number of charecter) of
> Conversation&  Contribution ID headers?
>        3) what will be the extension of an MMS file like pictute have .jpg
> etc?
>
> Kindly help me
>
> Thanks in advance.... :)
>

(Continue reading)

Worley, Dale R (Dale | 6 Jul 17:37 2012

Re: Call forward enabled and user calling himself

On Fri, 2012-07-06 at 10:53 +0530, Naarumanchi Kaushik wrote:
> 1. When a user calls himself(to the same endpoint), he will get User Busy
> response as his device is already busy. So a User busy response is sent
> based on his device status and not based on comparision between From and To
> URIs. Is this correct?

Generally, this is not correct.  In most SIP systems, an incoming call
for an extension will be routed to the phone even if that extension or
phone is busy.  And the phone will generally alert the user and give the
user an opportunity to put the current call on hold and answer the new
call.

I believe that this is because most SIP systems are made as business
phone systems, and historically business phones have had multiple lines,
and thus allow users to manipulate several calls at the same time.

As Paul notes, it can be difficult for the calling phone to place the
early dialog on hold, as the INVITE transaction has not completed.
However, it's possible that the phone could use an UPDATE to modify the
SDP of the early dialog, or simply stop rendering incoming media from
the dialog (without any protocol action).

In general, it is rarely useful for software to make any decision based
on the From and To headers, as they do not necessarily indicate unique
users or UAs, and because the actual UAS may be derived from the To URI
by many stages of forwarding.

> 2. If call forward always is enabled for this user, and if he calls
> himself, then giving priority to call forward is correct or not? Should
> this also be a User Busy response?
(Continue reading)

Worley, Dale R (Dale | 6 Jul 17:39 2012

Re: Call forward enabled and user calling himself

On Fri, 2012-07-06 at 10:39 -0400, Paul Kyzivat wrote:
> I've been waiting to hear of a possible pathology of this sort:
> You call yourself, or call somewhere that is routed back to you. Then 
> your phone gives you a call waiting indication. You put your current 
> call (the outgoing one) on hold and answer the incoming call. But then 
> you hear silence because the caller is on hold. You can then switch 
> between calls, but one end is always on hold. :-)

I've done such things using one of the old "key" phones.  It works
exactly as you'd expect it to...

Dale

Worley, Dale R (Dale | 6 Jul 17:41 2012

Re: Subscriber behaviour on expiration

On Fri, 2012-07-06 at 14:45 +0300, Jānis Rukšāns wrote:
> > Since the subscriber knows when the subscription is due to expire, and
> > knows that the notifier will send no further notifications after that
> > point, the subscriber knows exactly when the subscription expires, and
> > after that point, not to expect any more NOTIFYs.
> 
> In this case the final NOTIFY (3265bis 4.2.1.4 2nd paragraph) seems to
> be redundant, since the subscriber already knows that the subscription
> has expired.

Yes, it does seem to be redundant.  I suspect that it was specified to
be consistent with other termination cases (when the subscriber is not
expecting termination) and to ensure that there are no inconsistencies
when a one-time subscription ("Expires: 0") is made (as the one NOTIFY
sent is both the initiation NOTIFY and the termination NOTIFY).

Dale

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Gmane