Skip to main content

Re: SIP Servlet POJO 0.2 draft

  • From: Binod < >
  • To:
  • Subject: Re: SIP Servlet POJO 0.2 draft
  • Date: Mon, 18 Feb 2013 20:44:03 +0530

Hi Eric,

Please find the responses below.

On Monday 18 February 2013 07:17 PM, Eric Cheung wrote:
Hi Binod,
A few comments below.
Thanks
Eric

--------------------

1) page 1 says:
"Any Java method annotated with one or more annotations that carry the following SIP meta-annotations will be used by the container to deliver the messages to the application."

So it implies 1 or 2 of @SipMethod, @SipResponseCode, and @SipResponseRange can be omitted.

So is the method below allowed?

  // method 1
  @Invite
  public void handleInviteResponse(SipServletResponse response) {
    //...
  }

and is method 1 equivalent to method 2 below?

  // method 2
  @Invite
  @AnyResponse
  public void handleInviteResponse(SipServletResponse response) {
    //...
  }

If so, it seems @AnyResponse is unnecessary (but probably good to have as it makes the method annotation more explicit).

Yep. Right.


2) The Basic Rule, conflict resolution, Requests and Responses sections on page 8 may have some problem.

e.g. the Basic Rule on page 8 should address the case when any of ESm, ESc, ESr and ESp is empty (i.e. n=0). I think the subexpression should evaluate to true. Otherwise method 1 will never be selected.

Also the conflict resolution needs to be modified to address zero Sm, Sr or Sc.

e.g. consider the following 2 methods:

  // method 3
  @RedirectResponse
  public void handleRedirectResponse(SipServletResponse response) {...

  // method 4
  @Error300Response  // @SipResponseCode(value = 300)
public void handleMultipleChoiseResponse(SipServletResponse response) {...

when a 300 response comes in, it seems method 4 is more specific but the rule will select method 3.

(Perhaps an easy fix is to say for the Basic Rule, no annotation means the subexpression evaluates to true. For conflict resolution, the Jm with the least *positive* number of Sm is selected, followed by the Jm with zero Sm. Same with Sc and Sr. Also @AnyMethod do not count as Sm and @AnyResponse do not count as Sr. I think you are right, we dont need @AnyResponse. We only need @AnyMethod.

Yes. Agreed.



3) page 5 - 2) @AnyResponse

I think it should read

@SipResponseRange(begin = *100*, end = 999)

i.e. not 200


Ah, yes. Typo.



4) if there are 2 methods that can be selected for a specific request or response, but they have the same specificity using the method, code or range rules, what is the behaviour? Is it a deployment error?

I think, the primary responsibility will be with application
to make sure that there will not be methods with same specificity
for a specific request or response. We can specify that container "may"
throw a deployment exception. I am not sure, if container can do that for
all cases.

thanks,
Binod.








SIP Servlet POJO 0.2 draft

Binod 02/14/2013

Re: SIP Servlet POJO 0.2 draft

Eric Cheung 02/18/2013

Re: SIP Servlet POJO 0.2 draft

Binod 02/18/2013

Re: SIP Servlet POJO 0.2 draft

Lewis, Keith 02/18/2013

Re: SIP Servlet POJO 0.2 draft

Binod 02/18/2013
 
 
Close
loading
Please Confirm
Close