[reSIProcate] Not using Dum but Stack Apis for the Cancel

sumit p.sumit at teles.com
Wed Sep 28 20:46:04 CDT 2005


Hi Dennis

You have got me right .I am not using DUM at any point of time.Infact I 
am creating and sending the invite too using the stack API s and 
similarly creating and sending the cancel too using the stack APIs.On 
checking the structure of the Cancel and the Invite message find it to 
be the same too except the request line being Cancel instead of Invite. 
I am attaching the messages to show the structures.

INVITE sip:manoj at 192.168.115.33:5060;transport=udp SIP/2.0
To: <sip:manoj at 192.168.115.33:5060;transport=udp>
From: <sip:sumit at 192.168.115.41:5060>;tag=c490ff23
Via: SIP/2.0/ ;branch=z9hG4bK-d87543-9241de63a76b6936-1--d87543-;rport
Call-ID: 26d2e33fc1b20c5d at bGludXguc2l0ZQ..
CSeq: 1 INVITE
Contact: <sip:sumit at 192.168.115.41:5060>
Max-Forwards: 70
Content-Length: 0


CRIT | 20050928-184308.362 |  |  | RESIP:TEST | 0 | 1079976608 | 
testClient.cxx:119 | Client Received with response code 100
CRIT | 20050928-184308.362 |  |  | RESIP:TEST | 0 | 1079976608 | 
testClient.cxx:124 | Client Received with response code 180

CANCEL sip:manoj at 192.168.115.33:5060;transport=udp SIP/2.0
To: <sip:manoj at 192.168.115.33:5060;transport=udp>
From: <sip:sumit at 192.168.115.41:5060>;tag=c490ff23
Via: SIP/2.0/ ;branch=z9hG4bK-d87543-9241de63a76b6936-1--d87543-;rport
Call-ID: 26d2e33fc1b20c5d at bGludXguc2l0ZQ..
CSeq: 1 CANCEL
Content-Length: 0

INFO | 20050928-184328.367 |  |  | RESIP:TRANSACTION | 0 | 1079976608 | 
TransactionState.cxx:304 | No matching INVITE for incoming (from TU) 
CANCEL to uac
CRIT | 20050928-184328.367 |  |  | RESIP:TEST | 0 | 1079976608 | 
testClient.cxx:164 | Client Received with response code 481

Infact tried to find whether any such problem had existed earlier and it 
seems in the Changes Logs for resiprocate 9 there are some fixes for the 
same but not much information is present as to what was the actual 
problem and the fix for.

Regards and thanks
Sumit

Dennis Dupont wrote:

>Sumit
>
>I think what Asheesh is saying is that if you use DUM at all, you 
>must always use it.  But if you are sending the invite using the 
>stack API, there is no reason why you should not be able to cancel 
>using the same. 
>
>Can you please clarify whether you are using DUM for anything?   
>Also try logging the invite and cancel messages just before
>each is sent to the stack to be sure they match.
>
>Dennis
>
>  
>
>>-----Original Message-----
>>From: Asheesh Joshi [mailto:asjoshi at varaha.com] 
>>Sent: Wednesday, September 28, 2005 7:18 AM
>>To: p.sumit at teles.com; resiprocate-devel at list.sipfoundry.org
>>Subject: RE: [reSIProcate] Not using Dum but Stack Apis for 
>>the Cancel Message
>>
>>
>>You must use DUM for managing dialogues. Infact that is the 
>>only way you can manage dialogues in resiprocate.
>>
>>-Asheesh 
>>
>>-----Original Message-----
>>From: resiprocate-devel-bounces at list.sipfoundry.org
>>[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On 
>>Behalf Of sumit
>>Sent: Thursday, September 29, 2005 4:26 AM
>>To: resiprocate-devel at list.sipfoundry.org
>>Subject: [reSIProcate] Not using Dum but Stack Apis for the 
>>Cancel Message
>>
>>Hi All
>>
>>I am facing a problem when I am trying to create the Cancel 
>>message by using the stack APIs rather than DUM .
>>Problem: Always I am receiving a 481 message with the error 
>>being INFO | 20050928-154930.502 |  |  | RESIP:TRANSACTION | 
>>0 | 1079976608 | TransactionState.cxx:304 | No matching 
>>INVITE for incoming (from TU) CANCEL to uac
>>
>>I frame the Cancel Message in the following manner
>>
>>                   DeprecatedDialog dlog(mContact);
>>                    auto_ptr<SipMessage>
>>cancel(dlog.makeCancel(*backupInvite) );
>>                    mStack.send(*cancel);
>>
>>where backupInvite is obtained from
>>             
>>                   backupInvite=Helper::makeInvite( target, 
>>mContact, mContact);
>>                   backupInvite->setContents(sdp);
>>
>>Has anyone come across a similar problem?The problem on 
>>analysing I feel is the sip transaction id not matching.
>>
>>Regards
>>Sumit
>>
>>
>>_______________________________________________
>>resiprocate-devel mailing list resiprocate-devel at list.sipfoundry.org
>>https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>
>>
>>
>>    
>>
>_______________________________________________
>resiprocate-devel mailing list
>resiprocate-devel at list.sipfoundry.org
>https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>
>
>
>  
>






More information about the resiprocate-devel mailing list