Is 100 Trying not automatic?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 22, 2009 at 12:15 AM, Giorgio Bongiorni <g.bongiorni at selta.it>wrote:

> Hi Benny and all,
> I'm trying to implement a simple UAS to handle incoming INVITE requests. I
> first create the uas dialog, the sdp session and the invite uas session. At
> this point, I've obtained these logs:
>
> 16:52:12.651 sip_endpoint.c  Processing incoming message: Request msg
> INVITE/cseq=101 (rdata0x9a86694)
> 16:52:12.651   tsx0x9a94bdc  Transaction created for Request msg
> INVITE/cseq=101 (rdata0x9a86694)
> 16:52:12.651   tsx0x9a94bdc  Incoming Request msg INVITE/cseq=101
> (rdata0x9a86694) in state Null
> 16:52:12.651   tsx0x9a94bdc  State changed from Null to Trying,
> event=RX_MSG
> 16:52:12.651   dlg0x9a943d4  Transaction tsx0x9a94bdc state changed to
> Trying
> 16:52:12.651   dlg0x9a943d4  UAS dialog created
> 16:52:12.651   dlg0x9a943d4  Module mod-invite added as dialog usage,
> data=0x9a956a0
> 16:52:12.651   dlg0x9a943d4  Session count inc to 2 by mod-invite
> 16:52:12.651   inv0x9a943d4  UAS invite session created for dialog
> dlg0x9a943d4
>
> Now, if I want to send a 100 Trying provisonal response, I have to call the
> "pjsip_inv_initial_answer" function (or something like that). But, from
> RFC3261 - section 17.2.1: " When a server transaction is constructed for a
> request, it enters in the "Proceeding" state. The server transaction MUST
> generate a 100 (Trying) response unless it knows that the TU will generate a
> provisonal or a final response within 200ms [...] This provisonal response
> is needed to quench retransmission rapidily in order to avoid network
> congestion". Despite that, I've noticed that the transaction we create is
> not in the Proceeding state (it enters only after the
> pjsip_inv_initial_answer call):
>
> 17:01:53.384       endpoint  Response msg 100/INVITE/cseq=101
> (tdta0x8d0afc8) created
> 17:01:53.384   dlg0x8d083d4  Initial answer Response msg
> 100/INVITE/cseq=101 (tdta0x8d0afc8)
> 17:01:53.384   inv0x8d083d4  Sending Response msg 100/INVITE/cseq=101
> (tdta0x8d0afc8)
> 17:01:53.384   dlg0x8d083d4  Sending Response msg 100/INVITE/cseq=101
> (tdta0x8d0afc8)
> 17:01:53.384   tsx0x8d08bdc  Sending Response msg 100/INVITE/cseq=101
> (tdta0x8d0afc8) in state Trying
> 17:01:53.384  sip_resolve.c  Target '10.13.0.104:5060' type=UDP resolved
> to '10.13.0.104:5060' type=UDP (UDP transport)
> 17:01:53.384   tsx0x8d08bdc  State changed from Trying to Proceeding,
> event=TX_MSG
> 17:01:53.384   dlg0x8d083d4  Transaction tsx0x8d08bdc state changed to
> Proceeding
> 17:01:53.384        myapp.c  Call state changed to INCOMING
>
> I think this might be wrong. What happens if I wait before creating the
> provisonal response? Don't you think it would be better to automatically
> generate the 100 Trying response as soon as possible (e.g. inside the
> pjsip_inv_create_uas) and then give the control back to the user?
>
>
At pjsip level (not pjsua-lib), the stack doesn't know what the appropriate
action for the INVITE would be. It could be that the application would
automatically respond with 180, or even reject the call if the user is busy.
Hence it's not so wise to automatically respond it with 100, at the very
least that would be a waste of packet. So yes, as application programmer you
need to tell it exactly what to send initially.

I don't think there's nothing wrong here, unless if you decide not to send
anything.

At pjsua-lib level, the library has more knowledge about application state
(e.g. if user is busy), so it will send 100 automatically.

cheers
 Benny




> Thanks,
> Giorgio
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090522/dd6fec74/attachment.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux