Re: Click-to-dial issue with CVS version

Kathleen McCallum <[email protected]>
Newsgroups gmane.comp.voip.nist-sip
Message-ID <[email protected]> 
Hi all,

After making some changes for my click-to-dial implementation (making 
the ACK with the Dialog, and not the transaction) it still doesn't work. 
And I just read this from the documentation for jsip-1.2 (CVS),:

****************
javax.sip
Interface Dialog

....

  Invite Dialog States:
Null --> Early --> Confirmed --> Terminated Other Dialog-creating 
requests Dialog States (ie. SUBSCRIBE):
Null --> Confirmed --> Terminated.

The Listener MUST ACK the 2xx response associated with an INVITE dialog. 
Retransmissions of the ACK in response to subsequent INVITE requests are 
handled by the dialog layer. If a listener does not ACK a 2XX response 
immediately, the implementation will terminate the Dialog automatically 
and remove it from the stack when the listener completes its execution.
****************

Now, will I be able to implement any flow for 3pcc (RFC-3725)? since 
almost all of them send an ACK after the second invite is send?

4.1.  Flow I


              A              Controller               B
              |(1) INVITE no SDP  |                   |
              |<------------------|                   |
              |(2) 200 offer1     |                   |
              |------------------>|                   |
              |                   |(3) INVITE offer1  |
              |                   |------------------>|
              |                   |(4) 200 OK answer1 |
              |                   |<------------------|
              |                   |(5) ACK            |
              |                   |------------------>|
              |(6) ACK answer1    |                   |
              |<------------------|                   |
              |(7) RTP            |                   |
              |.......................................|



Is there any way I can work around this??? Am I getting wrong the idea???

Sincerely yours
Kathleen McCallum




M. Ranganathan escribió:
> Take a look at ResponseEvent.getDialog()
> 
> That should be non-null. You can use that to ack.
> 
> Regards
> 
> Ranga
> 
> Kathleen McCallum wrote:
> 
>> I was doing the ACK after the second part aswered the phone.  ( that's 
>> what the "flow I" recomends. But it doesn't reach that point since I 
>> check the response, and if clientTransaction is null I return (just 
>> before I send the dialog.sendAck(ackRequest) for the sencond and first 
>> Invite)
>>
>> ---
>> 4.1.  Flow I
>>
>>
>>              A              Controller               B
>>              |(1) INVITE no SDP  |                   |
>>              |<------------------|                   |
>>              |(2) 200 offer1     |                   |
>>              |------------------>|                   |
>>              |                   |(3) INVITE offer1  |
>>              |                   |------------------>|
>>              |                   |(4) 200 OK answer1 |
>>              |                   |<------------------|
>>              |                   |(5) ACK            |
>>              |                   |------------------>|
>>              |(6) ACK answer1    |                   |
>>              |<------------------|                   |
>>              |(7) RTP            |                   |
>>              |.......................................|
>> ---
>>
>> I will ACK it before sending the INVITE to B, and try and see if it works
>>
>>
>>
>> Kathleen McCallum
>>
>>
>>
>>
>> M. Ranganathan escribió:
>>
>>> You are not ACKing the 200 OK. Thats why the other end is 
>>> retransmitting 200 OK. After the first 200 ok the server tx is 
>>> terminated. Hence the null on the second 200 OK. If he is sending you 
>>> 200 OK you should ack it otherwise the other end is going to keep 
>>> retransmitting.
>>>
>>> ACK the dialog not the transaction : Dialog.createAck( 
>>> sequencenumber); .... Dialog.sendAck()
>>>
>>> does the trick
>>>
>>>  There is another tx:  z9hG4bKb6fc3c1ff123e1e365631d905e4dff5e 
>>> Absolutely no idea why he is timing out. Guess is you are not 
>>> providing the right credentials. He takes your invite, responds with 
>>> trying and then times out. . I suspect if you ACK the 200 OK he will 
>>> take your second invite.
>>>
>>> Ranga
>>>
>>> You should ACK the Kathleen McCallum wrote:
>>>
>>>> Ok, I'm sending you the response, it's between "++++++++++" characters
>>>>
>>>>
>>>> Thanks :)
>>>> Kathleen McCallum
>>>>
>>>>
>>>> M. Ranganathan escribió:
>>>>
>>>>> Print out the stray responses. I suspect they are not matching the 
>>>>> transaction for some reason. Send me another log with the stray 
>>>>> responses printed out.
>>>>>
>>>>> Ranga
>>>>> Kathleen McCallum wrote:
>>>>>
>>>>>> Hi M,
>>>>>>
>>>>>> Thanks for answering me. :)
>>>>>>
>>>>>> I just checked the Branch ID, and it's correct.
>>>>>>
>>>>>> Attached is the logs of my application, I hope they are usefull... 
>>>>>> In any case I can send you the debug logs.
>>>>>>
>>>>>> After I recieve the Proxy-Authorization request, I create again 
>>>>>> the INVITE request with the authorization.  It starts ringing on 
>>>>>> the other end.  But when I answer the phone, it all ends.
>>>>>>
>>>>>>
>>>>>> Thanks for your time
>>>>>> Sincerely yours
>>>>>> Kathleen McCallum
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> M. Ranganathan escribió:
>>>>>>
>>>>>>> Fairly sure this should all work. This is not enough information 
>>>>>>> to diagnose the problem. Are your 200 OK Branch ID matching the 
>>>>>>> outgoing INVITE? If you wish send me a debug log (if you are 
>>>>>>> absolutely sure its not a problem on your end). You may want to 
>>>>>>> check the branch ID first and make sure there is no mismatch.
>>>>>>>
>>>>>>> The TransactionTerminated event is fine. What do you do when you 
>>>>>>> get the Proxy-Authorization request? It will terminate the client 
>>>>>>> transaction. If the OK arrives after that you are going to see a 
>>>>>>> null tx id.  Thats what I think is going on. JSIP 1.1 RI had 
>>>>>>> several bugs that have been fixed hence you should really fix the 
>>>>>>> issue ( I have greater confidence that the JSIP 1.2 RI is correct ).
>>>>>>>
>>>>>>> Kathleen McCallum wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> After installing the JSIP-1.2 from the CVS my implementation of 
>>>>>>>> Click-to-dial is not working correctly, and now I really don't 
>>>>>>>> know where is the problem.
>>>>>>>>
>>>>>>>> I implemented the Flow I (from the RFC 3725)
>>>>>>>>
>>>>>>>> 1.  Invite "A" no SDP  ... OK
>>>>>>>> 2.  200 Offer1         ... OK
>>>>>>>> 3.  Invite "B" offer1  ... OK
>>>>>>>>
>>>>>>>> Afer I INVITE the sencond part ("B") I recieve :
>>>>>>>>
>>>>>>>> "Transaction Terminated event: 
>>>>>>>> javax.sip.TransactionTerminatedEvent[source=gov.nist.javax.sip.SipProviderImpl@30d83d] 
>>>>>>>> "
>>>>>>>>
>>>>>>>> But the flow goes on...
>>>>>>>>
>>>>>>>>
>>>>>>>> 4. Requests Proxy-Authorization ... OK (sinces it goes through a 
>>>>>>>> proxy)
>>>>>>>>
>>>>>>>> When "B" answers the call, I get something like this:
>>>>>>>>
>>>>>>>> "Response received with client transaction id null:
>>>>>>>> 200
>>>>>>>> SipBridgeSermanager - Stray response -- dropping "
>>>>>>>>
>>>>>>>> and after some of this messages I get a :
>>>>>>>> "SIP/2.0 408 Request timeout"
>>>>>>>>
>>>>>>>> I am not sure where is my error, since before I got the version 
>>>>>>>> 1.2 of JSIP my implementation was working correctly.
>>>>>>>>
>>>>>>>>
>>>>>>>> I would appreciate any comments you could give me, maybee I was 
>>>>>>>> doing something wrong before, but it worked somehow
>>>>>>>>
>>>>>>>> Sincerely yours
>>>>>>>> Kathleen McCallum
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> M. Rangnathan escribió:
>>>>>>>>
>>>>>>>>> Try getting the JSIP-1.2 RI from the NIST CVS  repository 
>>>>>>>>> (details on
>>>>>>>>> jain-sip.dev.java.net) and try the scenario again. It should 
>>>>>>>>> work. If it
>>>>>>>>> does not work, please post more details to the NIST-SIP mailing 
>>>>>>>>> list
>>>>>>>>> (not here -- this list is meant for the spec  not the RI).
>>>>>>>>>
>>>>>>>>> Ranga
>>>>>>>>>
>>>>>>>>> Kathleen McCallum wrote:
>>>>>>>>>
>>>>>>>>>> I've been searching around for a solution, but I had no luck :(
>>>>>>>>>>
>>>>>>>>>> When I recieve a BYE (from an INVITE) this request ask's me for a
>>>>>>>>>> proxy_authorization, but when I set the authorization I 
>>>>>>>>>> recieve a 481 "Call
>>>>>>>>>> Leg transaction does not exist".
>>>>>>>>>>
>>>>>>>>>> has anyone got a solution for it?  I thought about sending a 
>>>>>>>>>> Basic
>>>>>>>>>> authorization, but it seems already deprecated.
>>>>>>>>>>
>>>>>>>>>> Sincerely yours
>>>>>>>>>> Kathleen.
>>>>>>>>>>
>>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>> Visit the JAIN website at http://java.sun.com/products/jain
>>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> M. Ranganathan
>>>>>>>>>
>>>>>>>>> Advanced Networking Technologies Division,
>>>>>>>>> National Institute of Standards and Technology (NIST),
>>>>>>>>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>>>>>>>>> tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/
>>>>>>>>> Advanced Networking Technologies For the People!
>>>>>>>>>
>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>> Visit the JAIN website at http://java.sun.com/products/jain
>>>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> nist-sip mailing list
>>>>>>>> [email protected]
>>>>>>>> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.