Subject: [Sip] Re: MESSAGE advertising in REGISTERs

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Jul 2002 11:51:39 -0500

Certainly it will be needed to make many server related scenarios work. 
It is optional because MESSAGE can also be used in a pure end-to-end 
mode without assuming that such servers exist. For example, a MESSAGE 
UAC may discover the contact for a MESSAGE UAS from presence information 
(i.e. a contact in a presence doc), then send the MESSAGE request 
directly with no intervening servers. In this architecture, there is not 
necessarily a need to advertise support at a registrar.

Jiri Kuthan wrote:
> Can someone tell me why the MESSAGE I-D mandates advertising
> of support in REGISTERs of a MESSAGE-capable UAC only *optionally*?
> 
> Making it optional gains little knowledge to a SIP server -- a server 
> does not know anything it could reliably use in its processing logic.
> 
> Think of a SIP server which acts as a proxy server and message store.
> If it knew, that downstream UAS was not capable of processing MESSAGEs,
> it could immediately store an incoming MESSAGE, send 202 upstream,
> and relay the message to first UAC which registers and advertises support
> for MESSAGE in REGISTER.
> 
> Because the server does not know it, it has to relay unnecessarily 
> a message to an upstream UAS, which will deny it. Then, whenever 
> a REGISTER arrives, the server will try to dump message store to it,
> (hoping a UAC capable of MESSAGE registered) resulting in quite
> uneffective behaviour.
> 
> -Jiri

_______________________________________________
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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Jul 2002 13:19:52 -0500

What if there is no registrar?

Jiri Kuthan wrote:
> Though advertising MESSAGE capability in REGISTERs does
> not hurt in any scenario, not advertising hurts in some.
> That's why I would much prefer having it as a MUST.
> 
> -Jiri
> 
> At 06:51 PM 7/3/2002, Ben Campbell wrote:
> 
>>Certainly it will be needed to make many server related scenarios work. It is optional because MESSAGE can also be used in a pure end-to-end mode without assuming that such servers exist. For example, a MESSAGE UAC may discover the contact for a MESSAGE UAS from presence information (i.e. a contact in a presence doc), then send the MESSAGE request directly with no intervening servers. In this architecture, there is not necessarily a need to advertise support at a registrar.
>>
>>Jiri Kuthan wrote:
>>
>>>Making it optional gains little knowledge to a SIP server -- a server does not know anything it could reliably use in its processing logic.
>>>Because the server does not know it, it has to relay unnecessarily a message to an upstream UAS, which will deny it. Then, whenever a REGISTER arrives, the server will try to dump message store to it,

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 03 Jul 2002 20:12:37 +0200

-Jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 03 Jul 2002 14:57:37 +0200

-Jiri

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Jul 2002 16:17:01 -0400

> of support in REGISTERs of a MESSAGE-capable UAC only *optionally*?

Because the system will function without a proxy knowing this ahead of 
time. To date, we have not mandated the use of caller preferences (which 
is where this comes from) in other sip extensions, such as UPDATE, 
PRACK. I think presence mentions that you SHOULD do this, but not RFC 
3265 (i.e.,  it doesnt apply to all events).

Indeed, since not all methods are mandatory even in baseline SIP, and 
indeed, rfc3261 doesn't actually mandate anything but OPTIONS, we 
already have the case that a proxy doesn't know the methods of the UAs 
that register to it.

> does not know anything it could reliably use in its processing logic.

Sure it does. If it is there, it knows that the UA does or does not 
support MESSAGE. Its just that its not always there.

> a message to an upstream UAS, which will deny it. 

That doesn't seem so bad.

If it bothers you, send an OPTIONS to the UA once it registers.

> Then, whenever 

Well, that is only one way to handle transmission of undelivered 
messages to a UA when it comes online. For many reasons, it is not the 
best way, I think. A better way is allow a UA to query to see if it has 
any undelivered messages when it registers, and then pull them as 
needed. This works better in wireless, too. Even if the UA does support 
MESSAGE, it may not want all of them the moment it connects.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 06 Jul 2002 16:51:11 +0200

I still don't understand why you're opposed to mandatory 
advertising MESSAGE support in REGISTERs -- I'm not aware
of a harm and I am aware of a benefit in some scenarios.
Sending a message to a destination which could be known from 
its ads not to accept it is simply an unnecessary inefficiency.

Of course, I'm not worried about scenarios to which you 
refered and in which this capability is useless.

-Jiri

At 10:17 PM 7/4/2002, Jonathan Rosenberg wrote:

>Because the system will function without a proxy knowing this ahead of time. To date, we have not mandated the use of caller preferences (which is where this comes from) in other sip extensions, such as UPDATE, PRACK. I think presence mentions that you SHOULD do this, but not RFC 3265 (i.e.,  it doesnt apply to all events).
>
>Indeed, since not all methods are mandatory even in baseline SIP, and indeed, rfc3261 doesn't actually mandate anything but OPTIONS, we already have the case that a proxy doesn't know the methods of the UAs that register to it.
>
>Sure it does. If it is there, it knows that the UA does or does not support MESSAGE. Its just that its not always there.
>
>>Because the server does not know it, it has to relay unnecessarily a message to an upstream UAS, which will deny it. 
>
>>Then, whenever a REGISTER arrives, the server will try to dump message store to it,
>Well, that is only one way to handle transmission of undelivered messages to a UA when it comes online. For many reasons, it is not the best way, I think. A better way is allow a UA to query to see if it has any undelivered messages when it registers, and then pull them as needed. This works better in wireless, too. Even if the UA does support MESSAGE, it may not want all of them the moment it connects.
>
>
>-Jonathan R.
>
>
>
>--

---

From: Ben Campbell <[email-masked]>
Date: Mon, 08 Jul 2002 14:22:33 -0500

I do not understand why we would expect support of MESSAGE to give a 
client a higher requirement for registration than for clients that do 
not support MESSAGE.

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 10 Jul 2002 21:34:09 +0200

What I actually do not understand is why we have not
put this requirement on all supported methods. Fixing
it for a specific methods seems better (though ugly)
to me than fixing it for none.

-Jiri

At 09:22 PM 7/8/2002, Ben Campbell wrote:
>I do not understand why we would expect support of MESSAGE to give a client a higher requirement for registration than for clients that do not support MESSAGE.
>
>Jiri Kuthan wrote: