Subject: RE: [Sip] Comment on refer-with-norefersub-01

From: "Johnston, Alan" <[email-masked]>
Date: Mon, 07 Mar 2005 22:23:40 +0000

In most cases (at least for common ones such as transfer and remote call
control), the UA issuing the REFER has had some kind of SIP message
exchange with the REFER recipient.  As a result, the UA will know based
on a previously received Supported header whether the recipient supports
the extension before it sends the REFER with Require.

True, this doesn't cover all cases, but these cases seem like the most
common ones that would want to use this feature.  In other words, the
main reason for suppressing the subscription is that the UA has another
method of finding out the result of the REFER, and the number of
messages is trying to be minimized.

Thanks,
Alan Johnston
sip:[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Cullen Jennings
> Sent: Friday, March 04, 2005 10:38 PM
> To: Tom Hiller
> Cc: [email-masked]
> Subject: Re: [Sip] Comment on refer-with-norefersub-01
> 
> 
> 
> I think your are misunderstanding. I don't think it means this at all
> 
> It means the UAC sends it with the tag but no require. If UAS 
> supports it, great. If the UAS does not support it then the 
> refer still works and a NOTIFY is sent which the UAC promptly ends.
> 
> Now consider what would have happened if we did have the require.
> 
> UAC would send the refer, it would fail. The the UAC would 
> send refer without the tag. Then the UAS would send Notify, 
> then the UAC would cancel the subscription. 
> 
> It seems the first is case better for wireless - what am I 
> missing here.
> 
> 
> 
> On 3/3/05 1:19 AM, "Tom Hiller" <[email-masked]> wrote:
> 
> > Cullen,
> > 
> > 
> > Does this mean the mobile has to receive an immediate 
> notification due 
> > the REFER, then send a SUBSCRIBE to kill the implicit subscription, 
> > and then get yet another notification?
> > 
> > In practice, people draw message flows, count SIP requests and 
> > responses and other messages on a per "call" basis, and 
> then tally a 
> > total. In wireless it is sometimes important to minimize 
> the number of 
> > messages per "call".  "norefersub" reduces the number of 
> messages when 
> > one doesn't need the implicit subscription because the user 
> learns the 
> > notification information via existing subscriptions or via 
> other ways.
> > 
> > Also, some wireless spectrum is costly, and in some cases 
> there is a 
> > potential for lengthy SIP notification packets to interfere 
> with RTP 
> > packet flow due to lack of over-the-air connection 
> bandwidth. There is 
> > also a possible service impact of not being able transmit another 
> > message while sending a SUBSCRIBE to instantly end a subscription.
> > 
> > OMA has extensively incorporated "norefersub" into draft baselines 
> > (i.e., includes the option tag "norefersub" in the Require header). 
> > These draft baselines are now being readied for publication.  OMA 
> > requires the "norefersub" option tag in the Require header.
> > 
> > If I am misunderstanding the point of your comment, could 
> you expand 
> > further?
> > 
> > 
> > - Tom
> > 
> > Cullen Jennings wrote:
> > 
> >> It seems like in any case where you put a Require with the option 
> >> tag, it results in far more traffic and less chance of 
> >> interoperability than creating the subscription and 
> instantly ending 
> >> it.
> >> 
> >> I think you should say that the tag is not allowed in a Require.
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip