Sorry that I was late joining the meeting.
As a result I probably missed a discussion of the edge proxy use cases for Sip Outbound.
Later in the discussion we talked about providing a set of API methods and letting the application make the decisions. I was therefore surprised to see the summary saying that the container will do most things automatically.
We seemed to have no problem with the local registrar case - just need to decide the method names and data types to use. Your notes give an indication of the direction we are taking for this.
Could someone (perhaps Jean) write up the code samples for what the edge proxy will do to (a) generate the Path header containing a flow token and (b) process a Route header containing a flow token, these are the cases where it is less obvious how responsibilities will be split between the container and the application and what the API should be. It may be very similar to what was proposed at the F2F but having it written down will help to crystallise where we are in the discussion.
At a future meeting it would be good to discuss SIP_SERVLETSPEC-16 and decide whether we will implement it. There may be some linkage with the naming and types used for the "setFlow" method.
KeithOn Thu, Feb 7, 2013 at 4:49 AM, Binod < " target="_blank"> > wrote:
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 same lines
as we decided on F2F. We will augment that with an API that allow application (registrar)
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 session/proxy/proxybranch.setFlow(initialRemoteSipuri, localSipURI)
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.
-------------------- Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Thrupoint, Inc.
Re: Meeting Notes.