Re: [reSIProcate] [reSIProcate-commit] resiprocate 7042 nash: DialogUsageManager:
I would say AnswerReason act like Helper, so you don't have to dig into SipMessage to extract information again, which is the probably the reason you provide SdpContents as part of parameter.
Nash
On 4/21/07, Derek MacDonald <derek@xxxxxxxxxxxxxxx> wrote:
onAnswer provdes the SIP message that conveyed the SDP in the callback:
virtual void onAnswer(InviteSessionHandle, const SipMessage& msg, const SdpContents&, AnswerReason reason)=0;
which can be checked to see if it was a 200 or an ack; in any case, your application would always know if an invite or an ack is expected as that depends on the intial invite. I don't see the befefit of knowing if something is a re-invite; an application will be aware if an o/a exchange has occurred, if it cares.
PRACK introfuces many more o/a exhanges, which would require more values for this enum, and code to provde values for the enum. It also breaks the DUM encapsultion, which is trying to hide how o/a exhanges occur. A mid-dalog update should not look different than a mid dialog re-invite for most use cases.
Given your requirements the AnswerReason enum can be removed w/out compromising your application, and should be removed.
-Derek
On 4/20/07, Nash Tsai <nash.teltel@xxxxxxxxx
> wrote:
Hi Derek,
This was originally added in the TelTel-client branch, as is the DUM API offered couldn't tell the onAnswer triggered is a 200 OK or ACK, and I also made the distinction of first INVITE and re-INVITE, I haven't get into the details of understanding PRACK, all I know it's a PRE-ACK thing, can you explain why it will complicate PRACK development?
Nash
Hi Nash,
What is the motivation for InviteSessionHandler::AnswerReason? This adds complexity and doesn't really fit the DUM api, and will complicate PRACK development, or separating out the offer/answer state machine. I think we should remove this unless there is a compelling use case.
-Derek
| Project |
resiprocate |
| New Revision |
7042 |
| Committer |
nash (Nash Tsai) |
| Date |
2007-04-09 02:02:41 -0500 (Mon, 09 Apr 2007) |
Log
DialogUsageManager:
add ExternalMessageHandler interface
add hasEvent method
changes to process methods to allow mutex lock while in-processing
ClientRegistration/ClientSubscription/ClientPagerMessage/ClientPublication/InviteSession/ServerInviteSession/ServerPagerMessage:
Provide asynchronous method access by using command
Added:
Modified:
_______________________________________________
resiprocate-commit mailing list
resiprocate-commit@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-commit
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel