- From: Binod <
- Subject: Meeting Notes.
- Date: Thu, 07 Feb 2013 10:19:09 +0530
Attendees: Tom, Eric, Keith, Brian, Jonas, Nitzan, Jean, Binod (Sorry,
if I missed anyone).
- Here is what I think we had consensus on.
- Use a simple form of api, where container do most of the work on the
as we decided on F2F. We will augment that with an API that allow
to directly handle the flow.
- So, application will call SipServletRequest.setReuseConnection (feel
free to suggest name changes)
to indicate to the container that it handle RFC 5626 for various kind
of sip entities.
- Application can use methods like
SipServletRequest.getInitialRemoteSipURI and getLocalSipURI
to obtain an identity of the flow as per Jean's proposal.
- Application can later on use
to elect that flow and we will not use setOutboundInterface for the same.
- From an application composition perspective, it is similar to 14.2.1
of the spec.
o The settings of the last proxy application in a chain that used
the outbound apis will be used
by the container and that will override any previous settings.
o If the chain contains a UAS, then the previous settings will not
be relevant anymore to the remaining
- The FlowEventListener (may be name it a callback?) can be set on the
register request by the application.
- The FlowEvent will only return SipURIs.
SIP Servlet POJO.
- We did not conclude the discussion on this topic.
- There is one suggestion from EG to use a Matcher sort of mechanism to
match the requests based
on request uri etc (similar to the mechanism used in servlet mapping).
- Binod to continue incorporate Matcher to the design.