Subject: [Sipping] Re: MWI Draft and Proxy Server

From: Rohan Mahy <[email-masked]>
Date: Tue, 23 Mar 2004 13:04:37 -0800

On Mar 23, 2004, at 5:14 AM, Diego B wrote:

> Hi;
> I have a question regarding MWI SUBSCRIBE sent to a SIP Proxy server.
>
> In the draft I found:
> 3.13 Behavior of a Proxy Server
>
>    There are no additional requirements on a SIP Proxy, other than to
>    transparently forward the SUBSCRIBE and NOTIFY methods as required 
> in
>    SIP.  However, Proxies SHOULD allow non-SIP URLs.  Proxies and
>    Redirect servers SHOULD be able to direct the SUBSCRIBE request to 
> an
>    appropriate messaging notifier User Agent.
>
> What happen when the Proxy is not aware of an appropiate messaging 
> notifier server ?
>
> If the Proxy receives the following request:
> ( Assuming the Proxy is for Domain example.com )
>
> SUBSCRIBE sip:[email-masked] SIP/2.0
> To: <sip:[email-masked]>
> From: <sip:[email-masked]>;tag=78923
> Date: Mon, 10 Jul 2000 03:55:06 GMT
> Call-Id: [email-masked]
> CSeq: 4 SUBSCRIBE
> Contact: <sip:[email-masked]>
> Event: message-summary
> Expires: 86400
> Accept: application/simple-message-summary
> Content-Length: 0
>
> It will route the request to, using a Location Service based on 
> REGISTRAR information, to the UA that sends the SUBSCRIBE request

No, the proxy will forward the SUBSCRIBE request to ALL of contacts for 
that AOR simultaneously, including the UA that sent the SUBSCRIBE.  
Contacts that don't accept subscriptions for message-summary will 
return an appropriate error response.  Contacts which do will setup a 
subscription.

If the proxy supports caller preferences, it can also use 
accept-contact and reject-contact headers if provided to select a more 
appropriate Contact.

If my proxy doesn't have a contact for my voicemail server, then I will 
need to send my message-waiting subscriptions directly the appropriate 
URI.

thanks,
-rohan

> In the example the  subscriber is a UA ( a sip-phone ) with fqdn: 
> h1.example.com
>
>         Subscriber                 Proxy
>              |                       |
>              |  A1: REGISTER (new)   |
>              |---------------------->| Contact: sip:[email-masked]
>              |  A2: 200 OK           |
>              |<----------------------|
>              |                       |
>              |                       |
>              |                       |
>              |  A4: SUBSCRIBE (new)  |
>              |---------------------->|
>          SUBSCRIBE sip:[email-masked] SIP/2.0
>
>    The proxy looksup user in the registration database.
>              |                       |
>              |  A5: SUBSCRIBE        |
>              |<----------------------|
>
>
> Now from here is UA dependent.
>
> This is the correct Behavior for the Proxy? From the drafts and 
> RFC3261, the proxy is acting coorectly
>
>
> Thanks
>
> -- 
> Diego B
> MailVision Ltd.
> Tel.  : +972-4-8500505 ext 13
> e-mail: [email-masked]
> web   : http://www.mailvision.com
>
>

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

---

From: Diego B <[email-masked]>
Date: Wed, 24 Mar 2004 08:08:08 +0200

Hi;
Thanks

But if the UA that sends the SUBSCRIBE is the ONLY contact register for 
the AOR, it will be the only UA to receives the SUBSCRIBE, and normally 
this is not a messaging server.

The question arises because I found a UA that sends SUBSCRIBE, the proxy 
routes the SUBSCRIBE back to it (in tis case the UA is the only contact 
registered for the AOR), and it returns 202 (accept) but never sends a 
notify, so it keeps sending SUBSCRIBE to the proxy again and again.

So, the proxy is acting correctly, and the UA may send an apropiate 
error responce when the SUBSCRIBE get routed back to him?

Thanks

Rohan Mahy wrote:
>>    transparently forward the SUBSCRIBE and NOTIFY methods as required in
>>    Redirect servers SHOULD be able to direct the SUBSCRIBE request to an
> Contacts that don't accept subscriptions for message-summary will return 
> an appropriate error response.  Contacts which do will setup a 
> subscription.
> 
> If the proxy supports caller preferences, it can also use accept-contact 
> and reject-contact headers if provided to select a more appropriate 
> Contact.
> 
> need to send my message-waiting subscriptions directly the appropriate URI.
> 
> thanks,
> -rohan
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Mar 2004 09:23:46 -0500

> this is not a messaging server.

There is clearly something wrong here - not with the proxy, but with the 
configuration. If this is the way it is intended to be configured (there 
is no intent for a PA to be present) then it is stupid for the UA to be 
sending a subscribe.

Alternately, if there is a PA, but it is presently unavailable, then 
what you describe is appropriate behavior, but the resulting actions are 
wrong.

> notify,

This UA is broken. If it returns the 202, then it should send the 
NOTIFY. As you describe things, it most likely shouldn't accept the 
subscribe at all.

 > so it keeps sending SUBSCRIBE to the proxy again and again.

The UAC side of the UA is also broken. Why does it keep sending 
subscribe under the circumstances you describe?

> error responce when the SUBSCRIBE get routed back to him?

Yes. If it doesn't support subscribe at all it can return a 405. If it 
supports subscribe for other event packages but not this one, it can 
return 489. If it simply doesn't want to handle requests from itself it 
can return 403.

	Paul

>> No, the proxy will forward the SUBSCRIBE request to ALL of contacts 
>> for that AOR simultaneously, including the UA that sent the 
>> SUBSCRIBE.  Contacts that don't accept subscriptions for 
>> message-summary will return an appropriate error response.  Contacts 
>> which do will setup a subscription.
>>
>> If my proxy doesn't have a contact for my voicemail server, then I 
>> will need to send my message-waiting subscriptions directly the 
>> appropriate URI.
>>
>> thanks,
>> -rohan
>>

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 24 Mar 2004 12:41:55 -0800

On Mar 23, 2004, at 10:08 PM, Diego B wrote:

> Hi;
> Thanks
>
> But if the UA that sends the SUBSCRIBE is the ONLY contact register 
> for the AOR, it will be the only UA to receives the SUBSCRIBE, and 
> normally this is not a messaging server.
>
> The question arises because I found a UA that sends SUBSCRIBE, the 
> proxy routes the SUBSCRIBE back to it (in tis case the UA is the only 
> contact registered for the AOR), and it returns 202 (accept) but never 
> sends a notify, so it keeps sending SUBSCRIBE to the proxy again and 
> again.

The UA is behaving badly.  It should send a 420 Unsupported Event 
response, and a NOTIFY with Subscription-State: giveup

thx,
-r

>> accept-contact and reject-contact headers if provided to select a 
>> more appropriate Contact.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Mar 2004 04:31:14 -0500

one clarification inline:

> response, and a NOTIFY with Subscription-State: giveup

If the UA doesnt even know how to process a subscribe request, it 
returns a 405.

If the UA understands subscribe, but doesnt support the mwi event 
package, it returns a 489 (Bad Event). In such a case, the subscription 
has been rejected, and thus a NOTIFY would not be sent. Indeed, if one 
were sent, it would just be rejected by the subscriber with a 489, since 
no dialog was created.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Diego B <[email-masked]>
Date: Tue, 23 Mar 2004 15:14:23 +0200

Hi;

In the draft I found:

         Subscriber                 Proxy
              |                       |
              |  A1: REGISTER (new)   |

This is the correct Behavior for the Proxy? From the drafts and RFC3261, 
the proxy is acting coorectly

Thanks